How Password Managers Work — KDFs, Encrypted Vaults, and Zero-Knowledge Explained

"Put all your passwords in one place" sounds like the worst security advice possible — until you look at how that place is built. A modern password manager is a carefully engineered cryptographic system in which even the company running it cannot read your data. This post walks through the pipeline from master password to encrypted vault, what actually happens during sync and breaches, and why autofill is a phishing defence rather than a convenience.

The Pipeline: Master Password → KDF → Vault Key

Your master password is never used directly as an encryption key, and it is never sent to a server. Instead it goes through a key-derivation function (KDF) on your own device:

master password ("ferry-cactus-nylon-orbit-squad-lava")
        │
        ▼
KDF: PBKDF2 (600,000+ iterations) or Argon2id
  + per-user random salt
        │
        ▼
256-bit vault key  ──►  AES-256 encrypt/decrypt vault
        │
        ▼ (separately derived)
auth hash  ──►  sent to server to prove identity
                (server never sees the vault key)

The KDF's job is to be deliberately slow. PBKDF2 repeats a hash hundreds of thousands of times; Argon2id additionally demands large amounts of memory, which neutralises GPU farms. For you, unlocking costs a fraction of a second. For an attacker trying billions of master-password guesses, the same cost per guess turns a weekend of cracking into centuries.

The salt — a random value unique to your account — ensures two users with the same master password get completely different keys, and makes precomputed tables useless (the same trick that defeats rainbow-table style attacks).

The Vault: AES-256 Ciphertext

The vault itself — every username, password, note, and URL — is encrypted with AES-256, the same symmetric cipher used for government classified data. Decryption happens only in memory on your device after you unlock. On disk and on the sync server, the vault is an opaque blob:

• Without the vault key, AES-256 ciphertext is computationally unreadable — a brute-force of the key itself is physically infeasible
• Each entry is typically encrypted individually, so partial corruption doesn't destroy the vault
• Locking the manager wipes the decrypted data and key from memory

Zero-Knowledge: What the Server Never Learns

"Zero-knowledge" (or "end-to-end encrypted") architecture means all cryptography happens client-side. The server stores and syncs ciphertext; it authenticates you with a separately derived hash that cannot be reversed into the vault key. Consequences:

• The company cannot read your passwords, even under legal compulsion — it holds nothing readable
• Support cannot reset a forgotten master password — there is nothing to reset it against (this is why recovery kits exist; store yours safely)
• A malicious or compromised employee sees only encrypted blobs

Sync and What a Breach Actually Means

Cloud sync just replicates the encrypted blob across your devices; each device derives the key locally when you unlock. So what happens when a password manager company is breached — as has genuinely happened in the industry?

Attackers get encrypted vaults. To open yours they must guess your master password, paying the full KDF cost per guess. Run the numbers: at roughly 100,000 guesses per second against a well-configured KDF (an expensive rig), a 77-bit diceware master passphrase would take on the order of 10^10 years. A weak master password like "Monkey@123", though, could fall in hours. The lesson from real breaches is consistent:

• The architecture held — vaults with strong master passwords were not cracked
• Weak master passwords were the casualty — short, human-invented ones were crackable offline
• Old accounts with low KDF iteration counts suffered — check your settings and raise iterations if your account predates current defaults

Autofill Is a Phishing Defence

The most underrated feature is domain matching. A manager saves the exact origin along with each credential and only offers autofill when the current page matches:

Saved entry:  https://accounts.google.com  →  autofill offered
Phishing:     https://accounts-google.com  →  no match, nothing fills
Phishing:     https://google.com.verify-login.in  →  no match

Humans are fooled by lookalike domains, Unicode homoglyphs, and urgent-looking emails. String comparison is not. When your manager unexpectedly refuses to fill a login page, treat it as an alarm, not an annoyance — you may be looking at a phish. Manually copy-pasting the password into the page defeats this protection.

Local vs Cloud, and the Common Objections

Local-only managers (KeePass family) keep the vault file entirely on your devices — nothing to breach centrally, but you manage sync and backups yourself. Cloud managers (Bitwarden, 1Password, and similar) handle sync and sharing, relying on the zero-knowledge design above. Both are sound; the choice is about convenience versus self-reliance.

The usual objections, answered honestly:

• "One basket for all my eggs?" — Yes, but a basket built of AES-256 and a slow KDF, versus the real alternative: reused variations of one password across fifty sites, where one breached site opens all of them.
• "What if I forget the master password?" — Genuine risk. Use a memorable diceware passphrase, and store the emergency/recovery kit on paper somewhere physically secure.
• "Malware on my device could steal everything." — True, and equally true of typed passwords; a keylogger captures those too. Device compromise defeats every scheme, so this is not an argument against managers specifically.
• "The built-in browser manager is enough?" — Far better than reuse. Dedicated managers add cross-browser sync, secure sharing, breach monitoring, and stronger vault-lock behaviour, but the browser manager plus unique generated passwords already beats 95% of setups.

Frequently Asked Questions