Password Managers: What Happens If the Vendor Is Breached?

TL;DR

Yes, password manager companies get hacked. No, that usually does not mean your passwords are handed over, as long as you picked a good one and used a strong master password. A well-built password manager uses zero-knowledge encryption: the company only ever stores a scrambled blob they cannot read, because the key to unscramble it is made from your master password, which they never see.

• If the vendor is breached, attackers get the encrypted vault, not your actual passwords, provided your master password is long and strong.
• Your master password is everything. A weak one can be cracked offline after a breach; a long passphrase effectively cannot.
• The bigger real-world risks are not the vault itself: they are a weak master password, leaked metadata (like which sites you have accounts on, useful for targeted phishing), and malware or phishing on your own device.
• You should still use a password manager. The danger of not using one (reused and weak passwords everywhere) is far worse than the small, manageable risk of using a good one. Just make the master password a strong passphrase and turn on MFA (multi-factor authentication) for the manager itself.

Now for the more technical explanation

How a good password manager is built: zero-knowledge

The whole security model rests on one idea: the company should never be able to read your data, even if they wanted to, even if they are compromised.

• When you set a master password, the manager runs it through a key derivation function (KDF, such as PBKDF2 or Argon2) to produce an encryption key. This happens on your device.
• Your vault is encrypted locally with that key (typically AES-256) before anything is uploaded.
• The provider stores only the encrypted blob. They never receive your master password or the derived key. This is what “zero-knowledge” or “end-to-end encrypted” means.

So a breach of the provider’s servers gives an attacker your encrypted vault. To turn that into your actual passwords, they still have to defeat the encryption, which brings us to the one thing that really matters.

Why your master password is the whole ballgame

After a breach, an attacker has your encrypted vault and can attack it offline, on their own hardware, with no rate limiting and no lockouts. Their only route in is to guess your master password and re-derive the key.

• A short or common master password (or one you reused elsewhere) can be brute-forced or found in a wordlist. Game over for that vault.
• A long, unique passphrase (four or five random words, or more) has so many combinations that offline cracking is not realistically feasible.
• The KDF iteration count matters too. More iterations make each guess slower, so a higher count buys you protection. Modern managers use high defaults, but older accounts sometimes kept low ones from years ago, so it is worth checking and raising yours.

The takeaway: the encryption is not the weak point. Your master password is. Make it a strong passphrase you do not use anywhere else, and never store it inside the manager it unlocks.

What a breach actually exposes (and the LastPass lesson)

“The vendor was breached” can mean very different things depending on what was taken and how it was stored. The useful, real-world example is the LastPass breach disclosed in late 2022, where attackers obtained a backup of customer vault data.

Two lessons came out of it:

1. Encrypted fields stayed encrypted. Passwords and secure notes were protected by each user’s master password. Users with a strong master password and a high iteration count were in a genuinely defensible position, because the attacker was reduced to offline guessing.
2. Not everything in a vault is encrypted. Some fields, notably website URLs, were stored unencrypted, along with account metadata like email addresses. That does not reveal passwords, but it does reveal which services you use, which is a goldmine for targeted phishing (“we noticed unusual activity on your <exact bank you actually use> account”). Older accounts with low iteration counts were also more exposed to offline cracking.

The lessons generalise:

• A breach’s damage depends on your master password strength, the KDF cost, and what the product chooses to encrypt versus leave in the clear.
• Even with passwords safe, leaked metadata plus a known email address raises your phishing risk, so stay sharp about unexpected “security” messages after any breach.

The risks that are not the vault

For most people, the password database being cracked is not the most likely way things go wrong. These are:

• Phishing. You get tricked into typing your master password (or a site password) into a fake page. A good manager actually helps here, because it only autofills on the real domain, so if it does not offer to fill, that is a red flag.
• Malware on your device. A keylogger or infostealer on your own machine can grab your master password or your unlocked vault directly, no vendor breach required. Device hygiene matters as much as vault choice.
• A weak or reused master password, covered above.
• Losing access. A forgotten master password on a zero-knowledge system means nobody can recover it, by design. That is a feature for security and a risk for you, so plan for it (below).

Cloud, local, or self-hosted

Where your vault lives changes the trade-offs:

• Cloud managers (the mainstream option): most convenient, sync everywhere, the provider handles availability. You are trusting their zero-knowledge implementation and inheriting their breach exposure, which, as above, is manageable with a strong master password.
• Local-only managers (an encrypted file you keep yourself): no vendor to breach, but you own backup, sync, and the risk of losing the file. Good for people who want no third party in the loop.
• Self-hosted (you run the server): removes the big shared target, but now you are responsible for keeping that server patched and backed up, which is its own risk if you are not diligent.

There is no single right answer; it depends on how much convenience you want versus how much you want to trust yourself over a vendor.

What to actually do

• Use a long, unique master passphrase and store it nowhere inside the manager. Memorise it, and keep one offline emergency copy somewhere safe.
• Turn on MFA for the password manager itself, ideally a phishing-resistant method (a hardware key or passkey) rather than SMS.
• Check and raise your KDF iterations if your manager exposes the setting and your account is old.
• Keep the app, browser extension, and your device patched, and be cautious with browser extensions generally.
• Have a recovery plan: an emergency access contact, an export kept securely offline, or a written master password in a sealed location, so a forgotten password does not lock you out permanently.
• Consider passkeys where sites support them, which remove the shared-secret password entirely for those logins.

Should you still use a password manager?

Yes, without hesitation. The realistic alternative to a password manager is not “perfect passwords in your head”; it is reused and weak passwords across dozens of sites, which is precisely how most people actually get breached. A good password manager with a strong master password turns a vendor breach into a non-event for your passwords, and the leftover risks (phishing, device malware, metadata) are the same risks you already face and can manage.

Pick a reputable zero-knowledge manager, make the master password a strong passphrase, enable MFA on it, and you have moved yourself out of the group that account-takeover attacks find easy.

Related

• Building a phishing-resistant MFA setup for your important accounts
• Dark web monitoring: what it is, and why Have I Been Pwned does it free

Written by Tom Langston, IT Infrastructure and Cybersecurity.