Password managers: how they work and how to choose one
The short version. Generating strong passwords is the easy half of the problem. Keeping a different one for every account, on every device, without writing them on a sticky note, is the half that decides whether it works in practice. A password manager encrypts a vault with a key derived from one passphrase you memorise, and fills credentials only on the exact domain they belong to, which also blocks a category of phishing that no amount of password strength would have stopped.
What a password manager actually does
Underneath the autofill and the browser extension, a password manager is a small encrypted database and a key derivation function. The sequence is roughly this:
- You choose a master passphrase. It is never stored anywhere, in any form that can be reversed.
- The manager runs it through a slow key derivation function, typically Argon2id or PBKDF2 with a high iteration count, together with a random salt. Slowness is the point: it makes each guess in an offline attack expensive.
- The resulting key encrypts the vault with an authenticated cipher, usually AES-256-GCM or XChaCha20-Poly1305.
- Only the encrypted blob is ever synced or backed up. A good manager is designed so its own operator cannot decrypt it, which is what "zero knowledge" means in their marketing.
- When you unlock, the key lives in memory for a session, then is discarded on lock or timeout.
The consequence people find uncomfortable is that a forgotten master passphrase is genuinely unrecoverable. That is not a limitation the vendor could remove; it is the property that makes the design safe. Every manager offers some form of emergency access or recovery kit, and setting it up on day one is not optional.
The three kinds, and what each costs you
| Cloud synced | Local vault file | Built into the browser or OS | |
|---|---|---|---|
| Examples | Bitwarden, 1Password, Proton Pass, Dashlane | KeePassXC, KeePassDX, Strongbox | Chrome, Firefox, Safari with iCloud Keychain |
| Sync between devices | automatic | you arrange it yourself | automatic within the ecosystem |
| Works across browsers and platforms | yes | yes | usually not |
| Provider can be breached | yes, but the vault stays encrypted | no provider | tied to your platform account |
| Setup effort | minutes | an hour, plus sync to arrange | already there |
| Sharing with family or a team | built in | manual | limited |
| Best for | most people | people who want no third party at all | a first step, better than reuse |
The built in browser manager deserves a fairer hearing than it usually gets. It is free, it is already installed, and using it is dramatically better than reusing one password everywhere. Its real limitations are that it locks you into one ecosystem, that it historically ties vault security to your platform account rather than to a separate passphrase, and that sharing and secure notes are thin. If it is what gets you to stop reusing passwords, start there and move later.
What to look for before you commit
- End to end encryption with a key derived only from your passphrase. If the provider can reset your master password and give you your data back, they can also read it, and so can anyone who compromises them.
- A modern key derivation function. Argon2id is the current recommendation. PBKDF2 is acceptable at a high iteration count. Check what the default is and whether you can raise it.
- Published security audits and a public incident history. Every vendor of any size has had incidents. What matters is whether they disclosed them promptly and in detail, and what they changed afterwards.
- Open source, or at least an open client. Not a guarantee of anything on its own, but it means the encryption claims can be checked by people who are not paid by the vendor.
- Export in a standard format. You should be able to leave with a CSV or an unencrypted JSON export at any time. A manager that makes leaving hard is a manager that has stopped competing for you.
- Two factor authentication on the account itself, ideally with a hardware security key.
- Real apps on every platform you use, including the one you use least. The device with no app is the device where you will start reusing passwords again.
- Passkey support, if you expect to move away from passwords over the next few years.
- Breach monitoring, which tells you which stored password to change and when, so you can stop rotating on a calendar.
Setting one up without losing a weekend
- Create a master passphrase you have never used anywhere. Six or seven random words. Generate it on our generator with the "easy to remember" box ticked, and see the passphrase page for how to commit it to memory.
- Turn on two factor authentication for the manager account before you put anything in it.
- Save the recovery kit the manager gives you. Print it. Store the paper somewhere physically secure, away from the devices it protects.
- Import what your browser already has. Every manager can read a browser export. This gets you eighty percent of the way in ten minutes, and it also shows you exactly how many duplicates you have been carrying.
- Delete the browser copies afterwards and turn off the browser's own offer to save passwords, so you have one source of truth rather than two that drift apart.
- Do not rotate everything at once. Fix the accounts that matter first: email, then anything with money attached, then anything where you know you reused a password. Then let the manager's health report drive the rest over the following weeks.
- Change each one to a fresh 16 character random password as you go. The manager will offer to generate it; ours works just as well if you prefer to see the entropy figure.
Objections worth taking seriously
"It puts all my eggs in one basket."
It does, and that basket is encrypted, backed up, and defended by a company whose entire business depends on it holding. The alternative is not a safer arrangement, it is fifty accounts sharing three passwords, one of which is already in a public breach dump. Concentrating risk into something you can actually defend is usually the better trade.
"What if the company is breached?"
Assume it will be. That is why the vault is encrypted with a key the company never sees. A breach of the provider turns into a breach of your accounts only if your master passphrase is weak enough to brute force offline, which is precisely why it should be six or seven random words rather than something you invented. It is also why some vendors have been criticised for leaving old accounts on low iteration counts: check yours and raise it.
"What if I forget the master passphrase?"
Then the vault is gone, and no support ticket will bring it back. Mitigate it with the recovery kit, an emergency access contact if your manager offers one, and a paper copy kept somewhere physically safe for the first few months.
"What about passkeys? Is this all about to be obsolete?"
Passkeys replace the password with a key pair held by your device, so there is nothing guessable and nothing to phish. They are a genuine improvement and adoption is growing, but coverage is still partial: plenty of sites offer no passkey at all, and many that do keep a password as a fallback, which means the password still has to be strong. Every major manager now stores passkeys alongside passwords, so choosing one today is not a bet against passkeys, it is the thing that will hold both.