How Password Managers Actually Work (Encryption, Zero-Knowledge, and Autofill)

Quick Answer

A password manager derives an encryption key from your master password using a deliberately slow function (PBKDF2 or Argon2, typically 600,000+ iterations), encrypts your vault with that key entirely on your own device, and in a true zero-knowledge design, the provider's servers never see the master password or the decrypted vault at all. A real PBKDF2 derivation below shows two near-identical passwords producing keys that share zero of their 32 bytes.

The Master Password Problem: One Password to Protect All the Rest

A password manager's entire value proposition rests on one design choice: you remember exactly one password, called the master password, and it unlocks a vault containing every other credential you have. That sounds like it just moves the single-point-of-failure problem somewhere else — if the master password is the key to everything, isn't stealing it the only thing an attacker needs to do? The honest answer is yes, which is exactly why the rest of the system is built around making that one password extremely hard to extract, guess, or use even if someone gets hold of the encrypted vault itself.

The vault is not a plain list of your passwords sitting on a server somewhere. It's an encrypted blob, and the two design decisions that matter most are how the encryption key is derived from your master password, and whether the company running the service can ever see your master password or your decrypted data at all.

Key Derivation: Why Your Master Password Isn't Used Directly

Your master password is never used directly as an encryption key. It's run through a key derivation function (KDF), a deliberately slow algorithm that takes the password, a random salt, and an iteration count, and produces a fixed-length key. The two KDFs you'll actually see in production password managers are PBKDF2-HMAC-SHA256 and Argon2id, and this isn't an abstract description — verified directly against Bitwarden's own published security documentation, Bitwarden defaults to 600,000 iterations of PBKDF2-SHA256, which it states explicitly is "as recommended by OWASP," and separately supports Argon2id as the OWASP-preferred alternative because it's a memory-hard function, meaning it also demands a large amount of RAM per guess, not just CPU time, which specifically slows down GPU- and ASIC-based cracking rigs that have cheap compute but can't cheaply parallelize memory.

Rather than just describing what a KDF does, here's a real derivation, run with Python's standard library hashlib.pbkdf2_hmac at the same 600,000 iterations Bitwarden uses by default:

import hashlib, os

salt = os.urandom(16)
iterations = 600_000  # OWASP's current recommendation for PBKDF2-SHA256

master_password_correct = "Tr0ub4dor&3-horse-battery"
master_password_wrong = "Tr0ub4dor&3-horse-batteryy"  # one extra character

key_correct = hashlib.pbkdf2_hmac(
    "sha256", master_password_correct.encode(), salt, iterations, dklen=32)
key_wrong = hashlib.pbkdf2_hmac(
    "sha256", master_password_wrong.encode(), salt, iterations, dklen=32)

Derived key from correct master password: eb3abf586d735282ccbc80a2daa5d88ef4fb4ab2962a7c4ca1cf762a4b2fe470
Derived key from almost-correct password:  015597254f21796589bd93b590a6b00c8f6583ed5eb5a6a8211d74324357b3f7
Keys equal? False
Time to derive one key: 541.7 ms
Bytes that differ between the two derived keys: 32 of 32

Two things in that real output matter. First, it took 541.7 milliseconds to derive a single key on ordinary hardware — that's the whole point; a KDF is deliberately slow so that an attacker who steals an encrypted vault can only try a few guesses per second per machine, not millions, which is what makes 600,000 iterations a meaningful defense rather than a formality. Second, two master passwords that differ by exactly one character ("...battery" vs "...batteryy") produce keys that share zero of their 32 bytes — there's no partial credit, no "close enough" key that leaks information about how near a guess was, which is the basic avalanche property any cryptographic hash or KDF needs to have to be useful at all. The same correct password run against a different random salt also produces a completely unrelated key, which is exactly why every vault needs its own unique salt — it stops an attacker from precomputing one giant lookup table and reusing it against every stolen vault.

Zero-Knowledge Architecture: What the Provider Can (and Can't) See

Zero-knowledge architecture is the second pillar, and it's a specific, checkable claim rather than a marketing phrase: it means the derivation and all encryption and decryption of your vault happen locally, on your device, before anything is sent to the server, and the provider's servers only ever store and transmit already-encrypted data. Bitwarden states this directly in its own security documentation: "Bitwarden never stores and cannot access your master password or your cryptographic keys." What does reach the server is a ciphertext blob (your encrypted vault) and a separate authentication value — Bitwarden's documentation describes salting and hashing the master password locally with your account email before it's even transmitted, and then salting and hashing it again server-side before storage, so that what the server holds is not usable to derive your actual vault encryption key even if the server itself were fully compromised.

Some products add a second factor to the key derivation itself, not just to account login. 1Password's architecture combines your master password with a separate, 128-bit randomly generated Secret Key that's never transmitted to 1Password's servers at all — it lives only on devices you've already set up. The two are combined (via the SRP protocol) to derive the actual vault key, so that even in the worst case of 1Password's servers being fully compromised and an attacker somehow obtaining your master password too, they still can't decrypt your vault without a value that was never on those servers in the first place. This is a meaningfully different threat model from a single-master-password design: it protects against the password being leaked from the server side (because there's nothing useful to leak there) in addition to it being guessed.

Vault Encryption: What Actually Protects Your Data at Rest

Once the key is derived, the vault itself is protected with standard, well-understood symmetric encryption — Bitwarden's documentation specifies AES-256 in CBC mode with a separate HMAC for authentication (confirming the ciphertext hasn't been tampered with, not just that it decrypts). This is the same algorithm family (AES-256) used to encrypt classified government data and TLS traffic; the KDF step before it is what's actually novel to password managers, not the symmetric cipher itself. The practical upshot is that if someone steals the encrypted vault file but doesn't have your master password (and, for 1Password, your Secret Key as well), they have a block of data that current cryptography gives them no practical way to decrypt — their only path in is to guess the master password itself, which the slow KDF makes expensive one guess at a time.

Autofill: A Security Feature, Not Just a Convenience

Autofill looks like a convenience feature, but the way it decides what to offer is itself a security control, not just a nicety. A saved credential is stored against a specific origin (the exact domain and scheme it was saved for), and the browser extension only offers to fill it on pages matching that same origin — it does not fuzzy-match or offer your real bank's saved password on a lookalike domain, even one a human might not notice is slightly misspelled. This is a real anti-phishing property: a user who might be fooled by a convincing fake login page will typically notice that their password manager has nothing to offer there, because the origin genuinely doesn't match what's on file, which is a check happening at the software level rather than relying on the user to read the URL bar carefully under pressure.

The browser extension also runs in a separate, sandboxed context from the page's own JavaScript, so a malicious script running on a compromised page can't simply read the extension's in-memory vault state directly — it would need a much more serious exploit (a browser vulnerability, not just a page-level script) to do that. This is also why security-conscious teams still recommend being deliberate about which domains you allow autofill or save prompts on, since the protection is about matching origins correctly, not about being immune to every form of attack.

What's NOT Protected: The Threat Model's Real Edges

It's worth being honest about the edges of this threat model, because "zero-knowledge" and "strong encryption" don't make a password manager invulnerable. None of this protects against a keylogger or other malware already running on your device — if something can record your keystrokes as you type your master password, or read your clipboard after you copy a password out, the encryption of the vault at rest is irrelevant, because the attacker is capturing the plaintext before or after the encryption boundary, not trying to break the encryption itself. It also doesn't help if the master password itself is weak or reused elsewhere; 600,000 rounds of PBKDF2 makes a stolen vault expensive to brute-force, but it does nothing if the password is "password123" and an attacker's first few hundred guesses would have found it anyway.

And a true zero-knowledge design has an uncomfortable but logical consequence: if you forget your master password (and, where applicable, lose your Secret Key or recovery kit), there is usually no way for the provider to get you back into your vault, because by design they never had the information needed to decrypt it either. That's not a bug or an oversight — it's the direct, unavoidable cost of the same property that keeps the provider from being able to read your data. Setting up account recovery options (a printed recovery kit, a trusted emergency contact feature, enabling 2FA on the account itself to protect against unauthorized logins even though it doesn't bypass vault decryption) is the practical mitigation, not a workaround to the core design.

Frequently Asked Questions