Zero-knowledge password sharing explained

The term "zero-knowledge" appears regularly in security marketing. Password managers claim it. VPNs invoke it. Cloud storage services use it as a selling point. But what does it actually mean — and does it apply to how passwords are shared, not just stored?

This article breaks down zero-knowledge as a concept, explains where it applies to credential sharing, and helps you evaluate claims made by tools you might use.

What "zero-knowledge" means

In cryptography, a zero-knowledge proof is a way for one party to prove to another that they know a value, without revealing the value itself. Imagine proving you know the answer to a puzzle without telling anyone what the answer is.

Applied to software products, "zero-knowledge" has evolved into a broader claim: the service provider cannot access your data, even if they wanted to. The most common implementation is client-side encryption: your data is encrypted on your device, using a key derived from your password, before it is transmitted to the server. The server stores ciphertext — scrambled data that is useless without the key — and the key never leaves your device.

This means:

• The service provider cannot read your data
• A data breach of the server exposes only ciphertext, not plaintext
• Law enforcement requests to the server yield only encrypted data
• Even insiders at the company cannot access your information

How this applies to password sharing

Traditional password managers store your passwords in zero-knowledge vaults. But sharing creates a complication: if you encrypt data with your key and send it to someone else, they cannot decrypt it with your key — they need the data decrypted or re-encrypted with a key they hold.

Truly zero-knowledge credential sharing requires:

1. Client-side encryption: The credential is encrypted in your browser before being sent to the server
2. Key exchange: The decryption key is transmitted to the recipient separately from the encrypted data — typically embedded in the link itself (as a URL fragment, which is never sent to the server)
3. Server blindness: The server stores the ciphertext and generates the link, but never sees the plaintext credential or the decryption key

In this model, even if the server is breached, the attacker gets encrypted data and cannot decrypt it without the key — which only exists in the URL you sent to the recipient.

The URL fragment trick

The most common implementation of zero-knowledge credential sharing works like this:

• Your credential is encrypted in your browser using AES-GCM
• The encryption key is generated client-side and appended to the link after a # character (the URL fragment)
• The URL fragment is never sent to the server in standard HTTP requests — the browser handles it locally
• The recipient's browser receives the full URL (including the fragment), sends the server only the path (without the key), retrieves the encrypted data, and decrypts it locally

This is elegant because it uses a standard browser behavior to prevent the server from ever seeing the decryption key.

What "encrypted at rest" means (and does not mean)

Many tools claim to "encrypt data at rest." This is different from zero-knowledge. Encryption at rest means data is encrypted on the server's storage — but the server holds the encryption keys. The provider can decrypt your data. A server breach that also exposes keys could expose plaintext data.

Encryption at rest is significantly better than no encryption, but it is not zero-knowledge. The distinction matters when evaluating tools.

Why zero-knowledge matters for credential sharing

For most credential-sharing use cases — sharing a WordPress admin password with a client, delivering FTP credentials to a contractor — zero-knowledge encryption provides meaningful security benefits:

• If the credential-sharing service is breached, your credentials are not exposed
• The service provider cannot be compelled to hand over your credentials in plaintext
• There is no central server-side record of credentials that could be subpoenaed

For highly sensitive credentials — production database access, encryption keys, financial system credentials — zero-knowledge architecture is the appropriate standard.

Evaluating claims

When a tool claims zero-knowledge or end-to-end encryption for credential sharing, ask:

1. Is encryption performed client-side (in the browser)?
2. Does the server ever see the plaintext credential?
3. Is the decryption key transmitted separately from the encrypted data?
4. Can the provider access credentials if legally compelled?
5. Is the implementation open-source and independently audited?

Tools that can answer these questions with specifics are making a credible claim. Tools that use the term as a marketing tag without technical substance are not.

The technical detail matters because zero-knowledge is not just a marketing position — it is a specific architectural property that either exists or does not.