What Actually Needs to Be Protected
Before exploring how password manager security works, it helps to be precise about what the threat model is. The primary concern isn't someone guessing a single password—it's the scenario where an attacker gains access to the storage layer itself: a database dump, a compromised server, a misconfigured cloud bucket, or a rogue employee. In that scenario, how much damage can they do?
A well-designed system should ensure the answer is: nothing useful. Even with complete access to stored data, the attacker should be left with opaque ciphertext they can't decode without the user's key—which was never sent to the server.
That's the fundamental goal every layer of security is designed to serve.
Layer 1: Key Derivation from the Master Password
The user's master password is not stored anywhere—not in plaintext, not as a simple hash. Instead, it's used as the source material for deriving an encryption key through a deliberately slow mathematical function.
Why Key Derivation Needs to Be Slow
This is counterintuitive. In most software, slow functions are bad. Here, slowness is the entire point. An attacker who steals a database and wants to brute-force the master password must run the derivation function for every guess. If that function takes 300 milliseconds to compute, trying a million passwords takes roughly 83 hours on a single machine. If it takes 1 second, it takes 11 days. At scale, slowness translates directly into cost and time that makes brute force impractical against strong passwords.
Functions Used in Practice
The most widely used key derivation functions today are PBKDF2,bcrypt, scrypt, and Argon2. They each take a password, a random salt, and a work factor, and produce a fixed-length key. The salt ensures that two users with the same master password produce different derived keys, preventing precomputed lookup tables from being useful.
For a deeper look at how derivation functions are designed and why the parameters matter, see encryption key derivation.
Layer 2: Symmetric Encryption of Vault Data
The derived key is used to encrypt all vault data using a symmetric cipher—most commonly AES-256 in GCM mode. The credential records (passwords, notes, metadata) are encrypted client-side before anything is transmitted. What leaves the device is ciphertext.
What AES-256-GCM Provides
AES-256 provides confidentiality: data encrypted with the key cannot be read without the key. The GCM (Galois/Counter Mode) variant adds authenticated encryption, meaning the ciphertext includes an authentication tag. Any modification to the ciphertext—whether from a data corruption event or an active attacker—causes decryption to fail with a detectable error, rather than silently producing garbage data.
This property matters because confidentiality without integrity allows a subtle class of attacks where an attacker can modify encrypted data in predictable ways without decrypting it. Authenticated encryption closes that gap.
For specifics on what the 256-bit key length means in practice and why AES has remained the standard for over two decades, see AES-256 encryption standard.
Layer 3: Zero-Knowledge Architecture
Zero-knowledge (ZK) architecture is the structural principle that the server never sees data in decryptable form. Encryption and decryption happen exclusively on the client side. The server stores and retrieves ciphertext—it cannot read what it holds.
What the Server Does and Does Not Know
In a correctly implemented ZK system, the server stores:
- Encrypted vault data (ciphertext)
- Salt values used during key derivation
- Authentication material (a verification hash, not the key itself)
- Account metadata (email, subscription state, timestamps)
The server does not store:
- The master password
- The derived encryption key
- Any decrypted credential data
The practical consequence: if the server is fully compromised, the attacker gets ciphertext and salts. To do anything with the ciphertext, they must run key derivation against the master password—which they don't have—for every credential they want to access.
For a conceptual walkthrough of zero-knowledge design and how it differs from conventional server-side encryption, see what is a zero-knowledge password manager.
Layer 4: Transport Security
Even though data is encrypted before transmission, TLS (Transport Layer Security) is still essential. It protects metadata that isn't encrypted at the application layer—the fact that a particular user is accessing their vault at a particular time, the size of the response, and the authentication exchange itself.
TLS also protects against session hijacking and man-in-the-middle attacks during authentication. Certificate pinning on mobile clients adds an additional check that the client is talking to the legitimate server, not an intercepting proxy.
Layer 5: Client-Side Memory Handling
An often-overlooked attack surface is client-side memory. When a vault is unlocked, the decrypted data and the encryption key exist in the application's memory. A malicious process with sufficient privilege could read that memory.
Responsible implementations minimize the window of exposure by:
- Clearing plaintext from memory as soon as it's no longer needed
- Re-encrypting the in-memory vault after a configurable idle period
- Requiring re-authentication after the session times out
- Avoiding logging or persisting decrypted values in ways that might end up in crash reports or analytics
Web applications face particular challenges here because JavaScript doesn't provide reliable mechanisms for zeroing memory. Browser environments are inherently more permeable than native applications for this reason—it's a genuine limitation, not a gap in any specific product's design.
For the specifics of how encryption is implemented in a browser context, see client-side encryption explained.
How the Layers Interact
These five layers aren't redundant—they address different threat scenarios:
- Key derivation makes brute-force attacks against stolen data expensive
- AES-256-GCM ensures stolen data is unreadable and unmodifiable without the key
- Zero-knowledge architecture ensures the server can never be compelled to hand over plaintext
- Transport security protects the communication channel and authentication exchange
- Memory handling limits exposure on the device where data is legitimately decrypted
Removing any single layer doesn't immediately collapse the system, but it narrows the protection to the remaining layers. Defense in depth means that an attacker who successfully bypasses one control still faces several others.
What This Model Cannot Protect Against
Understanding the limits is as important as understanding the protections. This security model does not protect against:
- Compromised endpoint devices. If malware is running on the user's device with keylogging or screen-capture capability, it can capture credentials as they're typed or displayed, regardless of how well the vault itself is encrypted.
- Weak or reused master passwords. Key derivation slows brute force but doesn't prevent it against short or commonly used passphrases. The security guarantee scales with master password strength.
- Phishing. A convincing fake login page captures the master password before it ever reaches the legitimate application. No cryptographic mechanism prevents a user from handing credentials to an attacker directly.
- Supply chain attacks on the client code. If the application code itself is modified to exfiltrate the key or plaintext, the cryptographic layer is bypassed at the source.
These limitations don't mean the model fails—they mean the model solves a specific problem (server-side storage security and unauthorized data access) and relies on other controls for the scenarios it doesn't address.
Why These Choices Have Remained Stable
AES-256, PBKDF2 and its successors, and zero-knowledge architecture have been the foundation of reputable password manager design for over a decade. They've remained stable not because the field lacks innovation, but because they've withstood sustained scrutiny. New cryptographic primitives are adopted carefully and only after years of analysis—that conservatism is a feature of security engineering, not a limitation of it.