A password manager concentrates risk in one place, and people reasonably find that uncomfortable. The question is what it replaces. The realistic alternative is not a perfectly memorised set of unique passwords — it is reuse. And reuse means that one breach at any site where you had an account becomes a key to your email, and your email is the reset mechanism for everything else.
Credential stuffing — taking usernames and passwords from one breach and replaying them everywhere else — works because reuse is normal. A password manager is the only practical way for a person with a hundred accounts to have a hundred different passwords. That is the trade it offers: one well-defended target instead of a hundred weak ones.
So the useful question is not "is it safe" but "what exactly am I trusting, and what happens when that trust is tested". The LastPass incident is the best available answer, because it is the case where a major provider's vaults actually were stolen.
The design that matters is called zero-knowledge, and it is worth understanding because every claim in this article depends on it.
Your master password never leaves your device. Instead, software on your device runs it through a deliberately slow function — a key derivation function, or KDF — to produce an encryption key. Your vault is encrypted with that key locally. What the provider stores and syncs is ciphertext. They do not hold the key, so they cannot read your vault, and neither can anyone who takes a copy of their database.
Two consequences follow, and people are often surprised by both:
In 2022 LastPass disclosed a chain of incidents: an initial compromise of a development environment in August, and then, disclosed later that year, the theft of customer vault backups from cloud storage. Encrypted vaults belonging to customers were in an attacker's hands. If you want to know whether the architecture holds up, this is the test case.
The encryption. The vaults were not readable by taking them. There is no reported break of the underlying cipher, and no route from "I have the file" to "I can read the passwords" that does not go through guessing the master password. The zero-knowledge model did the job it claims to do.
Independent researchers subsequently attributed a series of large cryptocurrency thefts to credentials and seed phrases held in those stolen vaults, based on on-chain analysis and victim overlap. Treat that as a researcher attribution rather than an adjudicated finding — it is well argued and widely reported, and it was not established in court.
Every failure in that incident was a configuration or disclosure failure, not a failure of the idea. The vault design worked. What people lacked was a strong master passphrase, a current KDF setting, and any way to know what their provider left unencrypted. Those three things are checkable, and the rest of this article is how to check them.
Being clear about the limits is the only way the recommendation means anything.
| Threat | Does a manager help? |
|---|---|
| A breach at a site you use | Yes, substantially. Unique passwords mean the damage stops at that one account. |
| Credential stuffing | Yes. There is nothing to replay elsewhere. |
| Phishing pages | Partly. Autofill is origin-bound, so a manager silently declining to fill is a real warning sign. But you can still override it and type the password in yourself. |
| Malware on your device | No. A vault that is unlocked on a compromised machine can be read like anything else. See what an infostealer does. |
| Stolen session cookies | No. A stolen session does not need your password at all. |
| A weak master password | No. This is the one thing the design cannot cover for you. |
| Losing your master password | No — and that is deliberate. Plan for it instead. |
The overlap with our infostealer article is worth stating plainly rather than glossing: moving passwords out of the browser into a manager does not make a compromised machine safe. What it does is empty the single most automated target on your system, and give you a vault that can be locked, audited and rotated as one unit.
We are not going to rank products or quote prices — rankings go stale, prices change, and a recommendation you cannot verify is worth nothing. Here is what to actually check, in the order that matters.
1Zero-knowledge, documented. The provider should state plainly that encryption happens on your device and that they cannot recover your vault. If support can email you your password, walk away.
2A modern key-derivation setting you can see and change. Argon2id is the current preference; PBKDF2 is acceptable at a high iteration count. The test is whether you can find your own current setting in the app. If it is hidden, you are in the position LastPass customers were in.
3What is left unencrypted. Ask specifically about URLs, entry titles, attachments and shared-folder names. A provider that answers this clearly has thought about it.
4Independent audits, and an honest incident history. Published third-party audits with dates, and a record of disclosing problems promptly. A long history with no incidents is less reassuring than a history of handling them well.
5Two-factor authentication on the vault itself, plus passkey support for the sites you use.
6A real export. You should be able to get everything out in a portable format whenever you want. An export path is what stops the decision being permanent.
7Cloud sync or local only? Cloud-synced managers are convenient and are what most people should use. Local-only options such as KeePassXC keep the vault on your own disk with no provider to breach, at the cost of syncing it yourself. Both are legitimate; the local option asks more of you, and a vault you find annoying is a vault you will work around.
Well-known cloud options include Bitwarden, 1Password and Proton Pass; Apple and Google both now offer competent built-in options for people who live entirely in one ecosystem. That list is descriptive, not an endorsement — run each of them past the seven checks above, because the answers change over time and ours is not the verdict that should decide it.
1Make the master password a long passphrase. Several unrelated words, memorable to you, not a sentence anyone could guess from your life. You only have to remember this one, so it can afford to be long. Length beats complexity here.
2Write it down and store it physically. On paper, somewhere secure. This is not the bad advice it sounds like: the threat model for your master password is remote attackers, not someone burgling your filing cabinet, and the far more likely disaster is you losing access to everything.
3Turn on 2FA for the vault, and store the recovery codes offline — not in the vault they unlock.
4Import from your browser, then delete from your browser. Import, verify the entries arrived, then clear the browser's saved passwords and switch off its offer to save new ones. Skipping the deletion leaves you with two copies and the weaker one still exposed.
5Rotate in priority order, not alphabetically. Email first, because it resets everything else. Then banking and anything holding money. Then every account where you know the password was reused. The rest can wait for the next time you log in.
6Run the built-in audit. Most managers will flag reused, weak and breached passwords. That report is the actual to-do list.
7Set up emergency access. Decide now how a partner or executor reaches your accounts if something happens to you. Zero-knowledge means no provider will do it for them.
8Use passkeys where they are offered. A passkey cannot be phished or replayed the way a typed code can, because nothing reusable is transmitted. Most managers now store them alongside passwords.
This is a genuine trade-off and the confident answers on both sides are wrong.
Keeping time-based codes in the same vault as your passwords collapses two factors into one: whoever opens the vault has both. Keeping them separate preserves the second factor but adds friction, and friction is why people leave 2FA switched off.
A reasonable middle: let the manager hold codes for the long tail of ordinary accounts, where the alternative is realistically no 2FA at all, and keep the factor genuinely separate for the few that matter most — your email, your bank, and the manager itself — using a separate authenticator app or, better, a hardware key. Whatever you choose, SMS codes are the weakest option of all, because they can be taken by someone convincing your carrier to move your number.
A manager solves credentials. It does nothing about the other half of how accounts get taken, which is the published facts about you.
When an attacker cannot get your password, the next route is the process designed to help you when you have lost it. Account recovery and identity verification ask for a previous address, a phone number, a date of birth, a relative's name. Those are precisely the fields data brokers compile and sell. A perfect vault does not help if a support agent can be talked past with details someone bought for a few dollars — and the same details are what make a phishing message convincing enough to open in the first place.
We have written about the sharp end of this in what happens when a data broker gets your Social Security number, and about the general scope in what data brokers know about you.
A password manager fixes what you know. It cannot remove what is published about you — the addresses, phone numbers and relatives that answer security questions and make phishing land. Vigilant Privacy sends legal deletion demands to the brokers holding those records and tracks what each one does about it, for $9.95/month. Set up a password manager first; it is free and it matters more. Then deal with the rest.
Start free — no card requiredNo signup, no card, no data kept.