Password Managers: How Vaults Are Encrypted and What a Breach Exposes

People store login credentials, recovery codes, and private notes in password-manager vaults, trusting the service to keep them secret even if its servers are compromised. This security hinges on cryptographic design, the strength of the master secret, and user configuration choices. Below is a detailed look at the mechanisms protecting a vault, what attackers obtain in a breach, and which security settings offer the greatest practical protection.

Zero-Knowledge Encryption: The Core of Your Vault

Zero-knowledge (ZK) architecture means the provider never sees the data you store in plain text. Only the client device holding the master secret can decrypt a vault. In practice, the service stores an encrypted blob and a few metadata fields; it does not retain any copy of the raw decryption key.

Your master password never travels to the server. Instead, client software runs a key-derivation routine locally, transforming the password (plus a per-account salt) into a 256-bit symmetric key. This key then encrypts the vault using an authenticated encryption mode like AES-256-GCM. Because key generation happens entirely on your device, the server never learns the key, preserving the ZK guarantee.

Since the provider cannot reconstruct the key, it cannot read your vault even if compelled by a court order or a malicious insider. The provider may retain logs of account activity (logins, device fingerprints, IP addresses)—these are separate from the vault and the encrypted data.

The encryption standard most password managers use is AES-256, the same block cipher approved for classified U.S. government use. When used with a secure mode of operation (GCM, CCM, or CBC with HMAC), the algorithm provides confidentiality and integrity. AES-256’s key space (2^256) is beyond the reach of exhaustive search with current computing power; even a quantum computer would require impractically large resources to threaten it.

Master Password Strength and Key Derivation

Your master password is the single point of failure. If an attacker obtains it, the ZK barrier vanishes. Consequently, the password must be long and random enough to resist offline cracking attempts that often follow a data breach.

Key-Derivation Functions (KDFs) like Argon2, scrypt, or PBKDF2 deliberately slow down password hashing. An Argon2-ID configuration might use 4 × 1024 KB memory, 3 passes, and a parallelism factor of 2, taking around 500 ms to run on a modern laptop CPU. The same password hashed with a weaker PBKDF2-SHA256 set at 10,000 iterations would finish in under 50 ms, giving attackers a tenfold advantage. When evaluating a manager, check its published KDF parameters; higher memory cost and iteration counts increase the cost per guess for an attacker.

A practical guideline is to aim for at least 15-20 characters of high entropy. A passphrase of four unrelated words from a 2,000-word list provides roughly 44 bits of entropy (log2(2000^4)). Adding two random digits or symbols raises this to about 48 bits, still borderline for a determined attacker with GPU clusters. For stronger protection, target 60-70 bits, achievable with a mix of uppercase, lowercase, numbers, and symbols across 20-25 characters, or by using a full-entropy random string generated by the password manager’s own generator.

Reusing the master password across services is a common mistake. If a compromised site leaks the same password, an attacker can use it to unlock your vault. Because the password also serves as the input to the KDF, any exposure reduces the vault’s effective security, regardless of encryption strength.

What a Server Breach Actually Exposes

When a password-manager provider suffers a breach, attackers typically obtain these items:

1. Encrypted vault blobs – Each user’s vault is stored as a single ciphertext (often a JSON object, encrypted and Base64-encoded). Without the master secret, the blob is indistinguishable from random data.
2. Metadata – Some services store non-encrypted fields like entry titles, website URLs, and usernames to enable quick searches or auto-fill features. These are not covered by vault encryption because they are needed for server-side indexing.
3. Account-level logs – Timestamped login records, device identifiers, and IP addresses are usually kept for security monitoring.

The encrypted blob alone does not grant an attacker immediate access to passwords. However, metadata can be valuable. Knowing a user has an entry titled “Bank-Login” for bank.example.com identifies a high-value target. An attacker could craft a phishing email mimicking that site, increasing the chance of credential harvesting. Usernames (e.g., email addresses) are often visible, enabling credential-stuffing attacks on other platforms.

The practical limitation is that without the master password (or a successful offline brute-force attack on the KDF), the attacker cannot derive the AES-256 key and thus cannot decrypt the core secrets. Real-world cracking attempts on breached vaults demonstrate that a strong master passphrase combined with a memory-hard KDF renders brute-force attacks infeasible; typical GPU rigs can test at most a few thousand guesses per second on Argon2-ID with the parameters mentioned earlier, meaning a 60-bit password would take billions of years to exhaust.

Essential Security Settings for Peace of Mind

Even with a robust cryptographic foundation, operational security choices can significantly affect risk.

1. Mandatory Two-Factor Authentication (2FA) – Require a second factor (TOTP app, hardware security key, or FIDO2) for every login to the web or desktop client. If an attacker obtains a stolen password, the second factor blocks account access.
2. Strong, unique master passphrase – Enforce a minimum length of 15 characters and encourage the inclusion of multiple character types. Some managers provide a password-strength meter calibrated to the KDF cost; use it as a guide.
3. Emergency Access – Features allowing trusted contacts temporary vault access can be misused if not tightly configured. Set a mandatory waiting period (e.g., 48 hours) and require the contact to confirm via a separate communication channel.
4. Periodic master-password audit – Treat the master secret like a high-value credential. Change it at least once every 12-18 months, or immediately after any known compromise of a linked email account. Update KDF parameters if the provider releases a newer, stronger configuration.

A simple checklist for regular audits:

• [ ] 2FA enabled and tested on a separate device.
• [ ] Master passphrase meets length/entropy criteria.
• [ ] Emergency access recipients reviewed and waiting period confirmed.
• [ ] Last password change date logged; plan next rotation.

Maintaining these settings reduces the attack surface to the vault content itself, rather than to account-level compromise.

Choosing and Auditing a Password Manager

When selecting a manager, use a structured evaluation rather than relying on marketing slogans.

If a provider discloses audit reports, read the executive summary and any “critical” findings. If the report states “no significant vulnerabilities” but is older than two years, request information on subsequent internal penetration tests. For open-source options, the community can vet the code; however, ensure the maintainer has a documented release process and a responsible-disclosure policy.

Key takeaways

• Zero-knowledge encryption ensures only you can decrypt your vault; the provider never holds the key.
• Your master password is the decryption key; it must be long, high-entropy, and unique.
• A server breach yields encrypted blobs and limited metadata; without the master secret, core passwords remain unreadable.
• Enabling 2FA, using a robust master passphrase, and regularly reviewing security settings offer the greatest practical protection.

Frequently asked questions

Can a password manager company sell my data?

With true zero-knowledge encryption, the company cannot decrypt your vault data, so it cannot sell or misuse your stored passwords and private notes. It may monetize non-vault data, such as analytics on feature usage, but this does not include your encrypted secrets.

What happens if I forget my master password?

Typically, if you forget your master password and have not set up a recovery mechanism (like a stored recovery key or an emergency access arrangement), the vault becomes irrecoverable. The zero-knowledge design prevents even the provider from resetting the password, as the decryption key is derived solely from the secret you know.

Is using a password manager safe from hacking?

The vault itself is highly secure due to strong encryption and authenticated modes. Overall safety depends on your master password’s strength, the use of mandatory 2FA, and protecting your devices from malware that could capture the master secret at the point of entry. A well-configured manager greatly reduces risk compared to reusing passwords across services, but it is not immune to all attack vectors.

This article is for general information only. It does not constitute legal or security advice; laws and provider policies change, so verify current terms before relying on any service.