What is credential stuffing?
Credential stuffing is the automated use of username and password pairs stolen from one service to log in to other services, in the hope that the same person reused the same password. OWASP defines it as "the automated injection of stolen username and password pairs into website login forms, in order to fraudulently gain access to user accounts."
It is the reason a breach at a company you barely remember signing up to can end with someone in your email account.
The chain, in one picture
The sequence is short and each link is ordinary:
- A company is breached and its user records are taken.
- Those records circulate and are eventually aggregated into large lists of address-and-password pairs.
- Software takes each pair and tries it against many other sites, automatically.
- Wherever the person reused that password, the login succeeds.
- The successful pairs are separated out and used, or sold as verified working credentials.
Nothing in that chain requires the attacker to target you, know who you are, or break any encryption. You are one row in a list.
Why it is not brute force
These get conflated constantly, and the difference decides which defences work.
Brute force guesses passwords against an account — many attempts, mostly wrong, against one target. It is loud, and rate limiting and lockouts handle it well.
Password spraying inverts that: one common password tried against many accounts, slowly, precisely to stay under lockout thresholds.
Credential stuffing uses known pairs. As OWASP puts it, it "specifically uses known (breached) username / password pairs against other websites." Each attempt is a plausible, previously valid guess rather than a random one.
That distinction matters because the usual anti-guessing defences fit badly. There is no burst of wrong passwords against one account to detect; there is one attempt per account, from a different address each time, with a credential that may well be correct. From the login form's point of view it looks like a lot of people signing in normally.
Why a low success rate is not reassuring
Success rates per attempt in this kind of attack are low. People sometimes take that as comfort, and it is the wrong reading.
The attacker's economics are what matter. The credential list is free or cheap. The attempts are automated and cost almost nothing. So a small fraction of a list containing many millions of pairs still yields a large number of working accounts, and every one of them is a real person's account. A defender needs to be right every time; the attacker needs a fraction of a percent.
This is also why "my account is not interesting" is not protection. A working email account is useful regardless of whose it is: it unlocks password resets elsewhere, it sends convincing phishing to your contacts, and it can be resold.
What actually stops it
Unique passwords
This is the defence that removes the attack rather than mitigating it. If a password exists in exactly one place, a breach of that place exposes exactly one account, and there is nothing to stuff anywhere else. Everything else on this list is damage limitation by comparison.
Uniqueness at any real number of accounts requires a password manager. Memory produces patterns, and a pattern is not unique — it is a rule an attacker can apply. Why unique passwords matter more than complex ones covers why this is the bigger lever.
Multi-factor authentication
OWASP names multi-factor authentication as the primary counter-measure. A correct password stops being sufficient, so a stuffed credential fails at the second step.
It is not absolute. Codes delivered by SMS or push can be phished or fatigued out of people, and a session token stolen after authentication does not require the factor again. Prefer an authenticator app or a security key, and read what MFA does and does not protect against before treating it as finished.
Screening passwords against breach lists
If a service checks new passwords against a list of known-compromised values and refuses them, credentials that are already public never get established in the first place. NIST requires exactly this in SP 800-63B-4: compare a prospective password against "a blocklist that contains known commonly used, expected, or compromised passwords."
You can apply the same check to yourself. Checking whether a password you already use appears on a public list tells you whether it is currently stuffable.
What defenders run on the other side
If you operate a service rather than just use one, the controls that matter are documented in OWASP's Credential Stuffing Prevention Cheat Sheet: multi-factor authentication, breached-password screening at registration and change, device and connection reputation signals, and alerting on the population-level pattern — a rise in login attempts spread thinly across many accounts — rather than on per-account failures.
How to tell whether you are exposed
You cannot detect stuffing attempts against services you do not run. What you can determine is whether the raw material exists:
- Is the password on a public list? A breached-password check answers this directly. Compromised's Password Check hashes the password in your browser and sends only the first five characters of that hash, comparing candidate results locally — the service never receives the password. You can check a password without sending it.
- Was the address in a breach at all? That tells you whether a pair involving you is likely to be circulating.
- Did you reuse it? Only you can answer this, and if the honest answer is "probably, somewhere", treat that as a yes.
If the answer to the first is yes, the immediate steps are in what to do if a password was exposed.
For teams
The organisational version of this problem is that one employee's reused personal password can become an entry point into company systems, and no amount of internal policy affects the breach at the unrelated service where the password leaked.
The practical response is checking exposure for company addresses and having a defined sequence for what happens on a hit. Building a credential exposure response playbook sets that out, and the wider context is in the breach exposure guide.
Frequently asked questions
Does credential stuffing mean someone is targeting me?
Almost never. It is untargeted by design — your pair is one of many being tried mechanically. That is cold comfort in one sense and useful in another: it means the fix is structural, not personal.
If I have MFA, do I still need unique passwords?
Yes. MFA is a second door, and second doors are occasionally opened — by phishing, by session theft, by an account where you never enabled it. Unique passwords mean the first door was never openable, which is a stronger position.
Can a website tell me if my credentials were stuffed against it?
Some services notify you about a suspicious sign-in or a blocked attempt. Most do not tell you about failed attempts at all, because the volume would be meaningless noise. Absence of a notification is not evidence of absence.
Is it illegal?
Unauthorised access to a computer system is a criminal offence in most jurisdictions, including where the credentials were obtained from a public leak. This article describes the mechanism for defensive purposes only; it contains no operational detail and none is needed to act on the defences above.