A password reused somewhere else
The most impersonal entry in the table. Nobody is looking for you, and that is exactly why it works at scale.
- How often
- Common
- Typical size
- The account and its balance
- Recoverable
- Sometimes
- Cost to prevent
- Ten minutes, once
Uniqueness rather than strength
Strength protects against guessing, and guessing is not the attack. The attack is a credential pair leaked from an unrelated service being tried everywhere by something automated. A long complicated password reused somewhere that leaked it is exactly as useless as a short simple one, and the confidence it produces makes the situation worse.
What a second factor covers
| Attack | Stopped? |
|---|---|
| A leaked password tried later | Yes, completely. Exactly what it was designed against. |
| A live copy of the login page | No. It collects the password and the code together and replays both while the code is valid. |
| Something running on your own machine | No. Nothing on the account side helps. |
So it closes this entry and does nothing for rank two. Two different problems that look similar and need different answers.
The related rule about names
The same logic applies to the handle, with one difference that makes it worse. A password can be changed. A handle cannot, not without abandoning whatever record is attached to it, and anything posted under that name years ago becomes attached to this the moment a connection exists. Variations do not help, because variations are trivially matched.
The part people regret
Recovery material, saved at setup, before closing the page, kept separate from the password and not only on one device. Recovery without it is limited and frequently impossible, and the position nobody wants is holding a balance behind a challenge they can no longer answer. That failure has its own entry further down.
How the list reaches you
An unrelated service is breached, its credential pairs end up in circulation, and software tries them in bulk against everything worth trying. There is no targeting and no interest in you specifically, which is why nothing about being careful, low profile or uninteresting offers any protection at all. The only property that helps is that the pair being tried does not work here, and that property is uniqueness.
Where reuse actually happens
| Pattern | Why people do it | Why it fails |
|---|---|---|
| The same password everywhere | One thing to remember | One breach anywhere is a breach here |
| A base with a suffix per site | Feels systematic | Trivially derived once two examples are seen |
| An old password promoted to important use | It feels familiar and trusted | Familiar means it has been around long enough to leak |
| A strong password reused twice | Strength feels sufficient | Strength is irrelevant to this attack |
The manager question
A password manager solves uniqueness completely and introduces one thing worth thinking about: it is a single file that matters more than any password in it. Kept locally, backed up somewhere you control, with a passphrase you have not used elsewhere, it is a clear improvement over the alternatives. Kept in a service that syncs to somebody else's machine, it is a different set of trade-offs and the choice should be a decision rather than a default.