One password, ten sites: how credential stuffing opens accounts one by one

Most of what's written about credential stuffing is addressed to the people running the login page: rate limiting, bot detection, IP reputation, CAPTCHA. That's the defender's side of the wire. On your side there is really only one job, and doing it well is enough — make sure the pair that leaked somewhere else doesn't work anywhere that matters. This piece follows the chain from an old breach to an exchange account, and explains why "but my password is complicated" isn't the protection people think it is.

Stuffing isn't guessing

Start with the definition, because the whole thing turns on it. OWASP describes credential stuffing as the automated injection of stolen username and password pairs into website login forms, in order to fraudulently gain access to user accounts. It sits inside the brute-force family, but with a specific difference: brute forcing tries multiple passwords against an account — guessing, in other words — while stuffing replays known breached pairs against other websites.

That difference decides everything downstream. A sixteen-character password with symbols is excellent against guessing. It does nothing once that exact string has been copied out of some forum's database, because nobody is cracking anything — they have the plaintext. Complexity and uniqueness solve different problems: complexity stops guessing, uniqueness stops the chain reaction.

How one leak reaches your account

The chain usually runs like this:

1. The source has nothing to do with your money. A forum you last logged into years ago, a small shop you ordered from once, an app you installed for a discount code. Its database gets taken, and the email and password you signed up with enter circulation.
2. Breaches aren't the only source. Infostealer malware reads the password store in your browser directly and the haul joins the same datasets. Every site you use could have a spotless record and one bad install still puts you in there.
3. The data gets cleaned into pairs. Email, password, sometimes a phone number, formatted so a script can consume it.
4. It's replayed at scale. Requests come from large numbers of addresses, working site by site and account by account. Per account the cost is close to zero, so a low hit rate is perfectly acceptable.
5. Hits are sorted by value. Working logins are categorised, priced and resold, and exchange accounts sit high on that price list.

Note step five: there's usually a gap between an account being opened and anything happening to it. Yours may have been on a "confirmed working" list for weeks. "Nothing has gone wrong lately" is not evidence of safety.

Why exchange accounts sit near the top of the list

Break into a bank account and you still face transfer limits, payee checks and a clearing process that can be reversed. An exchange account is different: being logged in is already most of the way there — assets can be swapped into something else, orders can be posted, an API key with permissions can be created, an address can be dropped into the whitelist to sit out its cooling period. What leaves on-chain generally doesn't come back.

Which is also why a small balance is no defence. A verified account is a usable channel in its own right; and the password that opens it very likely opens the mailbox behind it, which is the recovery route for everything else.

How to tell whether you're already in it

Three things you can do yourself, most reliable first:

• The breach check inside your password manager. Every mainstream manager compares your saved entries against known breach data and tells you plainly: this one is exposed, that one is reused across five sites. Easiest and safest route. Browsers increasingly show the same warnings for passwords they store.
• A public lookup that only needs your email address. It tells you which published breaches your address appears in. A clean result is not proof of anything — much of this data circulates long before it is catalogued.
• The account's own records. Login history with cities and times that don't match, or verification codes arriving that you didn't trigger. That second one is a live signal that somebody is trying your credentials right now. See device management and suspicious logins.

Three steps that break the chain

1. One password per site, starting with three categories. You don't have to fix everything tonight. Go in order: mailbox, exchange, anything that moves money. Make those mutually different and never used elsewhere, and the worst segment of the chain is already cut.
2. Generate and store them in a password manager. Uniqueness only survives if you're not the one remembering. Give the manager a long master password used nowhere else, and turn on a second factor for the manager itself. If you're picking a memorable master password by hand, the UK's NCSC advice of three random words is a sound basis — length and unpredictability beat sprinkled symbols.
3. Add a second lock so the password isn't enough. An authenticator, a hardware security key or a passkey, plus the withdrawal whitelist. Together they separate "the password is correct" from "the assets can leave". Trade-offs are in the complete 2FA guide.

When that's done, the account security checkup will show what's still missing.

Three rules that changed

These three still show up in a lot of security advice, and all three are at odds with current NIST SP 800-63B guidance:

Why did forced rotation fall out of favour? Because someone made to change every quarter mostly adds a digit to the end. The rule looks stricter and the result is more predictable, while quietly encouraging reuse. What actually works is the unglamorous version: long, unique per site, kept in a manager.

FAQ