How passwords are attacked · 5 min read

Credential stuffing and password reuse

Credential stuffing needs no guessing at all: it replays a known email and password on other sites. Reuse is what makes it work.

Most discussion of password strength is about guessing. Credential stuffing skips guessing entirely. It takes an email address and password that leaked from one site and tries the same pair on many other sites. If the person used that password elsewhere, the attacker logs in on the first try.

Three attacks that are easy to confuse

The OWASP Credential Stuffing Prevention Cheat Sheet separates three login attacks:

Brute force and spraying are guessing; strength and blocklists are the defense. Credential stuffing replays a password that is already known. How long or random it is makes no difference once it is out.

How it works, step by step

1. A site is breached. Its user table leaks. Depending on how the site stored passwords, the attacker gets them directly or recovers the weaker ones by guessing against the hashes.
2. Pairs are collected. Recovered email and password pairs are combined with others into large lists.
3. Pairs are replayed. Automated tools submit each pair to the login pages of other services, often spreading attempts across many network addresses so that no single source looks unusual.
4. Matches are used. Wherever a person reused the password, the login succeeds.

Step 3 explains why ordinary rate limiting helps less here. A service that locks an account after many failures, as NIST requires (no more than 100 consecutive failures), is designed to stop guessing against one account. Credential stuffing makes one attempt per account. It does not need a second.

Worked example: what reuse costs

Suppose someone has 50 online accounts.

With one password shared across all 50. A breach of any one site exposes the password for every account. If that password is recovered, all 50 are open to replay: 50 out of 50, or 100%. Its strength helped only during step 1, and only if the breached site used slow, salted hashing.

With 50 unique, randomly generated passwords. A breach of one site exposes one password. The other 49 are unaffected. The exposure is 1 out of 50, or 2%, and the one that leaked is useless anywhere else.

Now add guessing back in. Say the breached site stored passwords with a fast, unsalted hash, and the reused password was an 8-character random string from all 94 printable characters (52.44 bits). On the site’s illustrative fast-hash rate of 10^11 guesses per second (an assumption, not a measurement), the average time to recover it is about 8.5 hours:

• 94^8 = 6,095,689,385,410,816 possibilities
• half of that ÷ 10^11 = about 30,500 seconds ≈ 8.5 hours

Eight and a half hours of computer time, in exchange for 50 accounts. With unique passwords, the same effort yields one account.

“Unique” has to mean unpredictable

A common habit is to keep one base password and vary it per site or per year: a site name at the end, or a number that goes up by one. Attackers who hold one version try the obvious relatives: other site names in the same position, the next and previous numbers, the same base with a different suffix. NIST SP 800-63B-4 notes that blocklist guidance “discourages trivial modifications of listed weak passwords,” and the same logic applies here. A derived password is only as independent as the rule that made it is secret, and rules like these are not secret for long.

Passwords that come from a random generator have no relationship to each other at all. Knowing one tells an attacker nothing about the next.

What services do about it

On the service side, OWASP lists layered defenses, and NIST sets several requirements that bear on stuffing:

• Multi-factor authentication. OWASP describes it as the strongest single defense against stuffing and spraying. A replayed password without the second factor fails. See two-factor authentication explained.
• Checking against breached passwords. NIST requires new passwords to be compared with a blocklist that includes “passwords obtained from previous breach corpuses.” A password already in a public breach corpus is one that stuffing lists may contain. See checking breached passwords with k-anonymity.
• Forced change on compromise. NIST says verifiers “SHALL NOT require subscribers to change passwords periodically” but “SHALL force a change if there is evidence that the authenticator has been compromised.” A breach is that evidence.
• Detecting automation. OWASP describes techniques such as device fingerprinting, monitoring for unusual login patterns, and notifying users of suspicious activity, while noting none of these alone is as effective as multi-factor authentication.

Why reuse persists

Reuse is not carelessness so much as arithmetic: dozens of accounts, each wanting a password, and one human memory. The practical way out is to stop memorizing most of them. NIST requires that services “SHALL allow the use of password managers and autofill functionality,” and notes that password managers “have been shown to increase the likelihood that subscribers will choose stronger passwords.” A manager, whether the one built into your browser or operating system or an open-source one, stores a unique random password per site, and you remember only one strong master password. The trade-offs are covered in password managers explained.

Note: Credential stuffing works on any reused secret, including PINs reused between services and answers reused across security questions.

Summary

• Credential stuffing replays known email and password pairs from one breach on other sites.
• One attempt per account is enough, so per-account limits and password strength do not stop it.
• Reuse multiplies one breach into many; unique passwords limit each breach to one account.
• Predictable variations of one base password behave like reuse.
• Services counter it with multi-factor authentication, breached-password checks and forced changes after compromise.

Generate a unique password for each account with the password generator.

General explanation, not advice for a particular situation. Updated 2026-10-31.