Quick answer
A data breach does not crack your password — it copies it. Complexity defends against guessing, and guessing is not what happened. The only property that limits the damage of a breach is uniqueness: if a password exists in one place, its exposure costs you one account. If it exists in twelve, one breach costs you twelve. That is why a long unique password from a password manager beats a clever memorable one everywhere.
The reframe
Picture two passwords.
One is Tr0ub4dor&3 — the sort of thing password advice used to produce. The other is mkq7-vane-portal-drift-9x, generated by a password manager and used on exactly one site.
Against an attacker guessing at a login form, both are fine. Rate limiting means nobody is guessing either of them.
Now the realistic scenario: a service you used is breached and its password table is taken. The attacker does not guess. They read. What they get is either your password directly or a hash they attempt offline, and in both cases complexity is not what protects you — the value has been taken, not deduced.
The question that decides your outcome is not "was it strong?" It is "where else did I use it?"
If the answer is nowhere, the breach costs you one account and ten seconds of annoyance. If the answer is your email, your shopping accounts and your work login, the breach costs you all of them, and it costs them automatically. Attackers take breached pairs and try them across other sites at machine speed — credential stuffing — and reuse is the entire condition that makes it work.
Why the old advice changed
For twenty years the guidance was: mix upper and lower case, add numbers and symbols, change it every ninety days. Current NIST guidance in SP 800-63B-4 reverses most of that.
- No composition rules. Verifiers "SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."
- Length instead. A minimum of 15 characters where a password is the only factor, and services should permit at least 64.
- No scheduled expiry. Verifiers "SHALL NOT require subscribers to change passwords periodically" — only where there is evidence of compromise.
- Screen against breach lists. New passwords must be compared against "a blocklist that contains known commonly used, expected, or compromised passwords."
The reasoning is behavioural. Composition rules and forced rotation both push people towards predictable transformations: a capital at the front, a 1 at the end, then 2, then 3. The rules produced passwords that satisfy a checker and are trivially predictable to anything modelling human habits.
Notice what the last rule implies. A password's value now depends on whether it has already leaked, which is a property of the world rather than of the string. correct-horse-battery-staple is a famously good password and a terrible one, because it is on every list.
A pattern is not uniqueness
The most common half-measure: a base password with a per-site suffix. Netflix2024!, Spotify2024!, Amazon2024!.
Character-wise these are different strings. Practically they are one password with a rule attached, and the rule is recoverable from a single example. Someone holding the breached Netflix2024! alongside your address does not need to be clever to try the obvious variants.
The same applies to keyboard patterns, a word plus a birth year, and the same base with different symbols. If you can derive password B from password A by a rule you could explain in a sentence, they are not independent.
Real uniqueness means no derivable relationship — which is not something people generate reliably by hand, which is the practical argument for a generator.
What "good" looks like now
Long. 15 characters minimum where the password is the only factor; longer for anything important. Length beats character variety.
Unique. One password, one account, no exceptions on the accounts that matter.
Generated, not invented. Human-chosen passwords cluster around patterns even when we try to avoid it.
Not already public. A password that appears in breach data is a known guess regardless of how it looks.
Memorable only where it has to be. You need to remember two: the password manager's master password, and your primary email password. Make those long passphrases. Everything else should be a random string you never see.
The password manager objection
The common worry: is putting everything in one place not a bigger risk?
It concentrates risk, and it is still a large net improvement, for two reasons.
The realistic threat is a breach at some service exposing a reused password. A password manager eliminates that entire class, because there is nothing reused to expose. The theoretical threat is a compromise of the manager itself — rarer, defended by encryption you control, and something you can protect with a strong master password plus multi-factor authentication.
There is also a second-order benefit that gets overlooked: a manager is an inventory. When a breach happens, it can tell you where a password was used. Without one you are trying to remember, and you will not.
Browser-built-in managers are a reasonable starting point and much better than reuse. A dedicated manager travels across browsers and devices more cleanly.
Where to start, if you are not starting from zero
Nobody converts forty accounts in one sitting. In priority order:
- Email. It is the recovery channel for everything else, so it is worth more than the rest combined.
- Anything holding money.
- Anything holding identity documents or health data.
- Anything with a stored payment card.
- Anything currently using a password you know is exposed.
- Everything else, as you use it. Change the password the next time each site asks you to sign in. Six months of that clears most of the list without a project.
Add multi-factor authentication as you go, at least on the first three tiers. What MFA protects against sets expectations for what that does and does not add.
Checking whether a password is already public
A password's exposure is a fact about the world, and you can look it up.
Compromised's Password Check does this without receiving the password: it is hashed in your browser with SHA-1, only the first five characters of that hash are sent, and the comparison against candidate results happens locally. The server sees a five-character prefix shared by hundreds of thousands of passwords, which is not identifying and cannot be reversed. That model — k-anonymity — is what makes it safe to check a password at all.
You can check whether a password you use is already public. If it comes back exposed, what to do if a password was found in a breach has the ordered response.
Frequently asked questions
Do I need to change all my passwords now?
No, and NIST explicitly advises against rotation for its own sake. Change the ones that are exposed, the ones that are reused, and the ones protecting things that matter. Leave the rest until you touch them.
Is a long passphrase as good as a random string?
For the two you must memorise, yes — several unrelated words are long and memorable. For the rest, a random generated string is better, because you are not memorising it and there is no linguistic pattern to model.
What if a site limits my password length?
Use the maximum it allows, keep it unique, and add MFA. A site with a low limit is telling you something about its engineering; treat any data you give it accordingly.
Are password hints and security questions safe?
No. NIST states plainly that verifiers "SHALL NOT prompt subscribers to use knowledge-based authentication", and hints accessible before authentication are prohibited. Where a site forces a security question, put a random string in the answer and store it in your manager.
Does uniqueness matter for accounts I do not care about?
It matters for the accounts you do care about, and reuse is how the ones you do not care about reach them. The cost of uniqueness is zero once a manager is generating them, so the question stops applying.