What Does "Zero-Knowledge" Actually Mean in a Password Manager?

Almost every password manager's landing page says some version of "military-grade encryption" and "we can't see your data." Very few explain what that actually requires, technically — or make it possible for you to check.

"Zero-knowledge" gets used loosely enough in marketing that it's worth being precise about what it actually means, what it takes to build correctly, and — just as importantly — what it doesn't protect you from.

The technical bar, stated plainly

A password manager is genuinely zero-knowledge only if all three of these are true at the same time:

1. The key never leaves your device. The encryption key used to protect your vault is derived locally, on your device, from your master password — using a slow, memory-hard function like Argon2id or PBKDF2, not a fast general-purpose hash. That derivation never touches the server, in any form.
2. Encryption and decryption happen locally. Every time an item is saved or read, the actual AES encryption/decryption runs in your browser or app — not on a server, even briefly, even "just this once for search indexing" (a surprisingly common shortcut).
3. The server only ever stores or receives ciphertext. Not "encrypted at rest" (which usually means the provider holds the key and encrypts their disks — they can still read your data on request). Ciphertext the provider cannot decrypt, plus the minimum non-reversible data needed to authenticate you.

Drop any one of these and you get something else: "encrypted," "encrypted at rest," or "we promise not to look" — all meaningfully weaker than zero-knowledge, and all frequently described using the same reassuring adjectives.

A concrete failure mode: the login step

The part people miss most often is authentication. If your password manager's server can compare your master password (or something directly derived from it) against a stored value to log you in, the server had to see that value at some point during login — which means it could have kept it. A correctly designed system never sends the encryption key or anything that trivially reconstructs it to the server, even during login.

How to actually check a vendor's claim (instead of trusting the landing page)

• Read the actual architecture page, not the marketing page. A vendor that's serious about this will publish which specific fields are cleartext on their servers and which are ciphertext — email address, sure; vault contents, no. If a "security" page is all confidence and no specifics, that's a signal.
• Check if the client is open to inspection. Open-sourcing the encryption/decryption code (even if the backend stays closed) lets anyone verify the client isn't quietly phoning home with plaintext.
• Ask what happens if you forget your master password. This is the single best litmus test that exists. If a vendor can reset or recover your master password for you, they can decrypt your vault — full stop. A real zero-knowledge product has no "forgot password" flow for your vault; losing your master password means losing your data, and any vendor being honest about their architecture will say so plainly instead of quietly offering a "friendly" recovery option.
• Look for a stated audit history — including admitted gaps. A vendor that's audited and lists exactly what was and wasn't in scope is more trustworthy than one that just says "bank-level security" with no specifics at all.

What zero-knowledge doesn't protect you from

This is the part vendors, understandably, spend less time on. Being honest about it matters more than the marketing copy:

How Spassword implements this

We built Spassword's encryption specifically to satisfy all three requirements above, not just the marketing version of them:

• Master key derivation via Argon2id, entirely on your device.
• HKDF splits that into an independent encryption key and auth key.
• Vault items are encrypted with AES-256-GCM — a fresh random IV every time, never reused.
• The server (Cloudflare Workers + D1) stores ciphertext, IVs, and a one-way verifier. Nothing else.
• No password recovery flow exists, by design — we tell you this before you sign up, not after you've lost your data.

We're also upfront about where we're not finished: Spassword hasn't been through a formal third-party security audit yet (we're a small, independent project — we'll pursue one as we grow), and our authentication currently uses a simplified verifier scheme rather than full SRP-6a. We'd rather say that plainly on our security page than let a confident tagline imply otherwise.