Quick answer
Unique passwords limit the spread of credential reuse across accounts. Password strength also matters, including when stolen hashes are attacked offline. Use long, unique passwords and multi-factor authentication together; none of these measures makes a breach harmless.
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.
Do not reuse either example as a real password. Online rate limits reduce guessing opportunities, but they do not make a known example safe or protect a stolen password database from offline guessing.
A stolen password table may contain plaintext or password hashes. Offline guessing resistance depends on the password and how it was stored. NIST’s password guidance addresses blocklists, rate limits and protected password storage; uniqueness addresses the separate risk of reuse across services.
The question that decides your outcome is not "was it strong?" It is "where else did I use it?"
A unique password limits direct credential reuse on other services, but recovering the affected account may still take time and require other actions. Attackers may test exposed credentials across services through credential stuffing; successful takeover is a risk, not an automatic outcome.
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.
A vault export is not an appropriate attachment to a troubleshooting request. If a message contains account identifiers, Safe Privacy Mask on IndieTools describes a tool for masking matching text before sharing it. Never rely on automatic masking to make a list of passwords safe to send.
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.
As you revisit old accounts, use their known addresses rather than reset links from unsolicited messages. An IndieTools SSL check can help investigate a certificate warning on a public hostname, but even a valid certificate says nothing about whether that site should receive your password.
Checking whether a password is already public
A password's exposure is a fact about the world, and you can look it up.
A password lookup can identify known exposed values, but it cannot prove that a new password will remain safe or that every incident is in its dataset. Review how a provider handles submitted data before using it.
For a known exposure, follow what to do when a password appears in a breach. For a new checking service, first read how to evaluate a breach checker safely. Unique passwords and multi-factor authentication remain useful even when a lookup returns no match.
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.
Revfaro
