Credential Stuffing
Credential stuffing is an automated attack that takes username and password pairs stolen from one breach and tries them against other services, at scale, betting that some people reused the same combination. It is not guessing. Every pair attempted is a combination that worked somewhere.
That distinction is the whole attack. A password policy defends against guessing; nothing about password strength defends against a correct password arriving from somewhere else.
| Attack type | Automated credential replay against login endpoints |
| Input | Breached credential pairs from dark web dumps and combolists |
| Typical success rate | A fraction of one percent of attempts — enough at scale |
| What it exploits | Password reuse across services |
| Usual outcome | Account takeover |
| Where it is catchable | Login, recovery, and the actions that follow a successful login |
How credential stuffing works
The raw material is a combolist — email and password pairs aggregated from breaches, deduplicated and sold or circulated freely. Billions of pairs are in circulation, and their value is not secrecy but volume.
The attacker loads the list into tooling that automates login attempts against a target, distributing them across residential proxy networks so no single address shows an unusual rate. Attempts are paced to blend into normal traffic, browser fingerprints are varied, and where a CAPTCHA appears it is routed to a solving service.
Success rates are low — commonly cited between 0.1% and 2% — and low is sufficient. A list of a million pairs run against a large consumer service yields thousands of working logins. Those are then either used directly or sold on as verified accounts, which command more than raw credentials because someone else has already done the work of confirming they open something.
The attack is cheap because every input is free or nearly so: the credentials already exist, the infrastructure is rented by the hour, and the target pays the cost of processing every attempt.
Why it matters for identity verification
Credential stuffing succeeds because the login is answering the wrong question. It asks whether the person knows the password, and the attacker does — correctly, completely, and because a real user chose it.
The defenses usually deployed are useful and each has a known limit. Rate limiting and bot detection raise the cost of volume, and attackers respond by lowering volume per address. MFA breaks the attack properly, which is why attackers concentrate on accounts that lack it and on the recovery flow that resets it. Breached-password screening blocks known pairs and does nothing for a reused password that has not surfaced yet.
What none of them addresses is the case that matters most: the attacker who gets through. At that moment the session is authenticated, the credentials are correct, and there is no remaining question about knowledge to ask — only a question about the person. That is why the strongest response to a high-risk login is not a harder knowledge check but evidence of who is present: a document and a matched, live face, escalated through risk-based authentication so the cost falls only on the attempts that warrant it.
Account recovery deserves the same treatment for a sharper reason. It is the designed bypass around every credential control, and after a successful stuffing run it is the first place an attacker goes to lock the real owner out.
Credential stuffing compared with related attacks
| Credential stuffing | Brute force | Password spraying | |
|---|---|---|---|
| What is tried | Known valid pairs from breaches | Many passwords against one account | One common password against many accounts |
| Knows the password worked somewhere | Yes | No | No |
| Defeated by password complexity | No | Yes | Partly |
| Defeated by account lockout | Partly | Yes | No |
| Primary defense | MFA, reuse detection, identity evidence | Complexity and lockout | Lockout across the population |
The row that matters is the third. Complexity rules are the control most organizations reach for and the one that contributes least here — a long, unique, well-chosen password is fully effective against stuffing right up until it is used on a second site.
What credential stuffing defenses cannot do
Rate limiting does not stop a patient attacker. Spread across tens of thousands of residential addresses at a few attempts each, the traffic is indistinguishable from ordinary login volume. Tightening the threshold starts locking out real users first.
CAPTCHA is a cost, not a barrier. Solving services price it per thousand, which converts a security control into a line item the attacker budgets for.
Forcing a password reset does not help if recovery is weak. Resetting every credential after a breach is sound, and it routes the entire user base through the recovery flow — which is exactly where an attacker holding the associated email is waiting.
Blocking known-breached passwords is always behind. A reused password only appears on a list once the breach containing it is public. Between compromise and disclosure, the pair is live and unknown.
Frequently asked questions
How is credential stuffing different from brute force?
Brute force tries many passwords against one account, hoping to find the right one. Credential stuffing tries pairs that are already known to be valid somewhere else. Password complexity defeats brute force and does nothing against stuffing, because the password is correct.
Why is the success rate so low and still worth it?
Because the inputs are nearly free. A success rate under 1% against a list of a million pairs still produces thousands of working accounts, and the credentials, tooling and proxies cost a small fraction of what those accounts sell for.
Does multi-factor authentication stop credential stuffing?
It stops the attack at the login, which is why enrollment matters more than policy — attackers concentrate on accounts that have not enrolled. It also redirects pressure to account recovery, which can reset the factor, so recovery needs to be at least as strong as the login it protects.
What should happen after a suspected stuffing attack?
Identify accounts with successful logins from the attack window rather than only resetting passwords broadly, check whether recovery details such as email, phone or payee information were changed after those logins, and treat changed recovery details as a takeover rather than a password problem.
Related reading
- Account takeover fraud — what a successful stuffing run is usually converted into
- Dark web — where the combolists are assembled and traded
- Risk-based authentication — how to escalate only the logins that warrant it
- Bot — the automation layer that makes the volume possible
