What a password manager actually protects
A friend told me over dinner that he would rather keep his passwords in his head than hand the lot to a company he has never met. He is a careful person and the objection is sincere.
He also had the same password on his email account and on a hotel loyalty scheme he signed up to in 2014.
That combination is the normal one, and the objection is aimed at the wrong thing. So start there, because until it is dealt with nothing else lands.
What the company is actually holding
Your master password never leaves your machine. It goes into a key derivation function that is slow on purpose, and what comes out is an encryption key. The key encrypts the vault locally. The thing that gets uploaded is the encrypted result, and it looks like noise.
The company stores the noise. It holds no copy of your key and has no way to reconstruct one from what it has. That is what “zero knowledge” means when a vendor uses the phrase properly, and it is checkable rather than promised: several of these products are open source and their sync protocols have been picked over in public.
The consequences are blunt. Staff cannot read your vault. An attacker who gets into the provider’s storage receives the same encrypted file their servers have. A legal demand produces something nobody in the room can open.
None of that rests on trusting anyone’s intentions. It is a fact about what sits on their disks.
Where the risk actually sits
Two places, and both of them are yours.
The master password comes first. If it is short, or reused from a site that has already leaked, then that encrypted blob becomes worth attacking. Somebody holding a copy can grind at it offline for months with no login form to slow them down. A long passphrase changes the arithmetic completely, because the derivation function is expensive per guess by design.
Then the device. While you are using the vault, it is decrypted in memory. Malware on the machine gets all of it and no architecture prevents that.
So the honest summary is that the vault is the strong part of this arrangement and you are the soft part. Worth knowing, because it happens to be the half you can fix.
Uniqueness is the product
Most write ups sell a manager on password strength, and strength stopped being the interesting question years ago.
A twelve character random string and a four word passphrase are both unguessable against a live login form, because the form rate limits and then locks after a handful of attempts. Nobody is working through combinations at your bank.
What no human can do is remember a different password for two hundred sites. That is the job the software exists to do.
The attack this actually blocks
Here is the sequence that empties ordinary people’s accounts.
A company you barely remember gets breached. An old fitness app, a forum, a shop you used once in a sale. The email and password pairs go on the market, and you are one line among several million.
Then the list gets replayed. Automated attempts across banks, mail providers, exchanges, retailers, anything worth having. That is credential stuffing, and it works purely because reuse is close to universal. The attacker broke nothing at the target. They logged in with credentials the target had every reason to accept.
Give every site its own password and the whole pipeline dies. The pair from the fitness app opens the fitness app. It opens nothing else.
State the benefit properly and it is this: a breach at one company stays a problem at one company. Everything else it does is convenience stacked on that one property.
The part that surprised me
Autofill turns out to be doing security work, and I ran a manager for years without noticing.
When it saves a login it records the address that login belongs to. On any page after that, it compares the address in front of it against the one it stored. If they fail to match, nothing appears. No prompt, no dropdown, no fill.
So a page that copies your bank down to the font, served from a domain one character different, gets an empty box from the software and a fully typed password from the human sitting in front of it. The manager reads addresses. It has no opinion about logos, and at eleven at night the human has nothing but the logo to go on.
The habit worth building: if autofill does not offer on a site where it normally does, read the address bar before typing anything. The silence is information.
Your browser’s built in one is fine
I am not going to tell you to go and buy something.
The manager in your browser generates passwords, stores them encrypted, syncs them, and does the address check. Against reuse, which is the actual problem, it does the job. Anybody moving from four reused passwords to the browser manager has captured most of the available benefit and can stop reading here.
The gaps are practical. It lives inside one vendor’s ecosystem, so an Android phone with a Mac laptop gets awkward quickly. Sharing a login with a partner is clumsy. It stores passwords and leaves out the other things you eventually want behind a lock, like account numbers or a scan of a passport. And a standalone manager usually installs as a browser extension, which is a permission grant that deserves a decision rather than a reflex.
If none of those gaps describe your life, use what you already have.
The failure mode is losing it
Every locked out person I have helped got there by their own hand. I have not once met somebody whose vault was stolen.
That asymmetry is designed in. Because the provider cannot read your vault, the provider cannot reset your master password. There is no working forgot password link. The property that keeps their staff out keeps you out on the day you need it.
Which makes recovery planning more important than which product you pick, and almost nobody does any.
Write the master password on paper, by hand, and keep it where you keep your passport. Paper syncs itself nowhere, and the thing you are defending against here is your own memory in three years.
Export the vault every few months, encrypt the export, and leave it on a drive in a drawer. Having a plain copy anywhere feels wrong, which is precisely why people skip the step and then have nothing at all.
Set up emergency access if the product offers that, where a person you name can request the vault after a delay you choose. Two weeks in hospital and somebody still has to pay the bills.
What actually leaks when a manager gets breached
It has happened. It will happen again. The useful question is what leaves the building.
The encrypted vaults leave, and they are exactly as good as the master password wrapped around them. That is the reason to make that one password long and unlike anything else you have ever typed.
The metadata leaves with them, and this is the underrated half. The list of site addresses in a vault is often stored unencrypted so the client can work quickly. An attacker holding that learns which bank you use and which exchange you keep coins on without decrypting a single entry, which is more than enough material to write you a persuasive email.
Old vaults leave with old settings. A vault created eight years ago is frequently still running the iteration count that was standard back then, a fraction of what the product ships with today. Raising it is a toggle on a page almost nobody opens.
If your vault has been alive for years, go and look at it once. Raise the iterations if the option exists. Change the master password to something long. That is one afternoon, and it moves an offline attack from feasible to not worth starting.
The part I got wrong
I adopted a manager about six years ago and did it half way, which felt like caution at the time.
Everything low stakes went in. Forums, shopping, newsletters. My registrar, my bank and my main email I deliberately kept out, on the grounds that putting the important ones into a company’s vault seemed reckless.
Those lived in my head instead, on a system. A base phrase with a variation per site, which I was quietly pleased with.
Then a site I had used it on turned up in a breach and I sat reading my own pattern in plain text. Two samples and anybody could have generated the rest.
So the accounts I had guarded most carefully were carrying the weakest passwords I owned, and the reason is that I made them myself. Hand made passwords get reused, because a hand is attached to a memory. The random entries I never once looked at were the only ones that were sound.
I also left emergency access unconfigured until this year, which is the same mistake wearing a different coat.
Where to start
Not with two hundred accounts. People who try that give up on day two.
Email first, because every other account you own has a reset link that lands in it. Generate a new password, save it, move on.
Then anything holding money. Then the domain registrar, if you own domains.
After that let it happen by attrition. Every time you log into something, let the manager save it and change the password while the settings page is already open. It takes months and it never costs you an afternoon.
Then run the breach report your manager almost certainly includes, once, across the whole vault. It tells you which saved passwords have already appeared in a public dump, and the count comes back higher than people expect.
More privacy tools tested honestly, failure modes included, are here.