Are password managers actually secure? How the encrypted vault works

LastPass suffered a breach in 2022 that exposed the encrypted vaults of millions of users. The company's response was, in essence: "the data is encrypted, you're safe." Technically correct — but with a catch that most news coverage never properly explained. Understanding that catch is what separates people who use password managers securely from those who just have a false sense of protection.

If you haven't read about how to create strong passwords before landing here, the post how to create and store strong passwords is the starting point — this one assumes you already know what entropy is and why P@ssword1 is garbage.

How the encrypted vault works

A password manager doesn't store your passwords. It stores an encrypted blob that contains your passwords. The distinction matters.

When you create an account with Bitwarden, 1Password, or any decent competitor, here's what happens:

1. Your master password never leaves your device in plaintext.
2. It goes through a key derivation function — PBKDF2, Argon2, or similar — that transforms the password into an encryption key. This process is deliberately slow (hundreds of thousands of iterations) to hinder brute force.
3. The vault is encrypted locally with AES-256 using this derived key.
4. Only the encrypted blob goes to the provider's servers.

The server never saw your master password. Never saw your passwords. It only stores data that, without the derived key, is random noise.

This is the zero-knowledge model: the provider has no knowledge of the vault's contents. It can't hand your passwords over to a government, can't sell them to advertisers, and when it suffers a breach — because eventually it will — what leaks is ciphertext with no immediate utility.

What the LastPass breach actually exposed

Back to the 2022 case: what the attackers obtained were encrypted vaults. To access the contents, they need each master password individually. People with a strong, long, unique master password were safe. People with lastpass123 as their master password... well.

The real problem with LastPass wasn't the encryption model — it was that some unencrypted metadata (site URLs, folder names) was also exposed. And that the PBKDF2 iteration count was lower than it should have been for many older users. Technical details that surface-level coverage ignored.

The real threat model

Password managers aren't unbreakable. The point is understanding where the real risk comes from.

The server isn't the primary vector

With zero-knowledge, compromising the provider's server gives an attacker encrypted vaults — useless without the master passwords. The more relevant vector lies elsewhere.

The device is the primary vector

If malware with a keylogger is running on your computer when you open the vault, it captures the passwords in plaintext before they reach the clipboard. No server architecture solves this — it's an inherent weakness of any system that eventually displays data on screen.

The mitigation is keeping your OS updated, not installing random browser extensions, and using the manager's biometric/PIN authentication when available (reduces how often you type the master password).

Browser extensions: the neglected attack surface

The manager's browser extension has access to the DOM of every page you visit. That's necessary for autofill to work — but it also means a compromised or poorly implemented extension could leak data. Prefer extensions from providers with published independent security audits. Bitwarden and 1Password have them; check the date of the last one before trusting.

Phishing risk with autofill

Good managers do autofill based on the exact domain — mybank.com won't fill in myb4nk.com. That's real protection against phishing that typing manually doesn't offer. But it only works if you let the manager control the filling, not copy-paste manually from wherever.

Master password: the only failure point you control

With zero-knowledge, the entire system's security depends on one thing: the strength of your master password. The server can't recover it. Tech support can't reset it. If you forget it, the vault is gone.

That's a feature, not a bug — but it requires you to take it seriously.

A master password for a password manager doesn't need to follow the same rules as regular passwords. It needs to be:

• Memorable. You'll type this one frequently. It can't be a 30-character random hash.
• Long. 4-5 random words in sequence (diceware) provide sufficient entropy and are memorable.
• Unique. Never use anything you use elsewhere as a master password.

# Example diceware master password (don't use this exact one):
# "brick-drawer-fuse-cloud-432"
# ~68 bits of entropy — brute force with current hardware: infeasible

Enable two-factor authentication on your manager account. MFA doesn't protect an already-downloaded local vault, but it protects against someone who obtained your master password trying to access the online account and download the current vault.

Local vs. cloud-based manager

There's a third option beyond the big SaaS players: local managers like KeePassXC, which store the vault in a file on your device (or wherever you sync it).

The tradeoff is straightforward: you eliminate the risk of a third-party server breach, but take on the responsibility of backup and sync. If the hard drive dies without a backup, the passwords are gone. For most people, the convenience of cloud with audited zero-knowledge is the right balance. For those with specific compliance requirements or justified paranoia, local makes sense.

Is it worth using?

The question that should have a clearer answer than it usually gets: yes, without hesitation.

The alternative scenario is reusing passwords across services — and there the risk is certain, not hypothetical. Credential stuffing works because most people reuse passwords. When any service you use suffers a breach (and one will), attackers automatically test the leaked credentials against every other service. A reused password is a chain of dominoes.

The manager solves the real human problem: it's impossible to memorize 80 long, unique passwords. Not because people are lazy — because human memory wasn't designed for that.

The manager's risk exists, but it's comparatively smaller and more controllable than the alternative. And for building the habit of generating passwords with real randomness, I use the Password Generator — especially handy when setting up new accounts without having to open the manager's internal generator.

Frequently asked questions

What happens if the password manager's server gets hacked?

With a correctly implemented zero-knowledge model, the attacker gets encrypted vaults. Without the individual master passwords, the data is useless. The real risk is for users with weak master passwords — offline brute force on downloaded vaults is possible and does happen. A strong master password is the effective protection in this scenario.

Is a browser password manager (Chrome, Safari) the same thing?

Not exactly. Native browser managers sync with a Google or Apple account — which don't implement zero-knowledge in the same way. Google can, in theory, access your saved passwords. They're also locked into the ecosystem: Chrome passwords don't migrate easily to Firefox, or to devices outside Android/Chrome OS. For casual use it may work; for real security, a dedicated manager with audited zero-knowledge is superior.

Do I need to pay for a secure manager?

No. Bitwarden is open source, third-party audited, and the free plan covers most use cases. The code is public — anyone can audit what runs on the client. For individual use, the difference between free and paid is features (password health reports, priority support), not fundamental security.

What if I forget my master password?

With real zero-knowledge, there's no recovery. The provider has no way to access the vault. Some services offer emergency access (via a trusted contact) or recovery kits — which are simply a copy of the key stored securely by you. The practical solution is keeping the master password written physically in a safe place (a physical safe, sealed envelope in a trusted location) and never relying solely on memory.

Note: the editorial content ends here. What follows is a recommendation for a tool related to the post's topic.

Related tool

To generate passwords with real cryptographic randomness — the kind worth storing in your vault — the Password Generator uses crypto.getRandomValues directly in the browser, without sending anything to a server.