Credential Stuffing: How Reused Passwords Get You Breached

Somebody breached a forum in 2019. Your employee had an account there, using the same password they use for work email.

That is the entire attack. Credential stuffing turns one old, unrelated breach into thousands of account takeovers, and it needs no exploit, no malware, and no skill beyond running a script.

What makes it dangerous is that nothing about it looks like an attack. The password is correct. The login succeeds. Your systems behave exactly as designed.

This guide explains how credential stuffing works, why it defeats most traditional defences, the controls that actually stop it, and what to do when it succeeds.

What Is Credential Stuffing?

Credential stuffing is an automated attack in which stolen username and password pairs from one breach are tested at scale against other services, exploiting the fact that most people reuse credentials.

The attacker is not guessing. They are replaying combinations that were genuinely valid somewhere else.

Credential Stuffing vs Brute Force vs Password Spraying

These three get conflated constantly, and the distinction determines which defence works:

Brute force tries many generated passwords against one account. Rate limiting and lockout stop it.

Password spraying tries one common password against many accounts, staying under lockout thresholds.

Credential stuffing tries known-valid pairs harvested from breaches. Because each attempt uses a real password, success rates are far higher and the traffic looks legitimate.

Account lockout — the classic answer to password attacks — barely helps against credential stuffing, because the attacker rarely needs more than one attempt per account.

How the Attack Works

Acquire credentials. Breach dumps and combination lists circulate on criminal marketplaces, often aggregating billions of pairs from years of incidents.

Select targets. Attackers prioritise services where an account has cashable value — banking, retail, loyalty points, streaming, corporate SSO.

Automate at scale. Off-the-shelf tooling handles request generation, session handling, and CAPTCHA-solving services.

Distribute the traffic. Requests are spread across residential proxy networks and botnets so no single IP looks abnormal.

Rotate fingerprints. User agents, device fingerprints, and timing are varied to defeat naive detection.

Harvest the hits. A small success rate across millions of attempts still yields thousands of working accounts.

Monetise. Accounts are drained, resold, used for fraud, or — in the corporate case — used as a foothold for lateral movement.

Step seven is where a consumer nuisance becomes an enterprise breach. A valid SSO login is a far better starting position than any phishing payload.

The whole sequence is industrialised. Credential stuffing is sold as a service, complete with fresh combination lists, proxy pools, and configuration files tuned to specific target sites — which is why defending against it is not a one-time project.

Why Credential Stuffing Is So Effective

Password reuse is near-universal. People maintain dozens of accounts and a handful of passwords.

Breaches accumulate. Credentials leaked years ago remain useful because passwords change rarely.

The login is legitimate. No malware, no exploit, no signature to detect.

Traffic blends in. Distributed sources mean per-IP thresholds never trigger.

Detection is asymmetric. Defenders must spot a handful of successes hidden inside normal login volume.

Cost is trivial. Lists and tooling are cheap; the economics work at very low success rates.

The credentials themselves frequently arrive through phishing in the first place — see our explainer on what phishing is and the broader survey of phishing attack types.

Defences That Actually Work

The OWASP Credential Stuffing Prevention Cheat Sheet is the reference implementation guide. The practical hierarchy:

1. Multi-Factor Authentication

MFA is the single highest-impact control, because a stolen password alone stops being sufficient. Priorities:

Cover every authentication path, including legacy protocols and API endpoints. Partial coverage means attackers simply find the uncovered door.

Prefer phishing-resistant factors — FIDO2 security keys or passkeys — over SMS codes.

Move away from simple push approval, which is vulnerable to fatigue attacks, toward number matching.

2. Breached Credential Screening

Check passwords against known-compromised sets at registration, at change, and periodically thereafter. NIST’s authentication guidance in SP 800-63B recommends screening chosen passwords against lists of known-compromised values rather than relying on composition rules.

3. Bot Detection and Rate Limiting

Rate limit by identity, device fingerprint, and behavioural signal — not by IP alone.

Deploy bot management that scores request patterns rather than blocking address ranges.

Use adaptive challenges, presented on suspicion rather than to every user.

4. Behavioural and Contextual Signals

Impossible-travel detection across successive logins.

New-device and new-location step-up authentication.

Anomalous login velocity per account.

Alerting on a spike in *failed* logins that is followed by a spike in *successful* ones — the signature of a stuffing run finding hits.

5. Password Policy That Reflects Current Guidance

Prioritise length over forced complexity.

Drop mandatory periodic rotation, which pushes people toward predictable variations.

Encourage password managers so unique credentials become practical rather than aspirational.

Support long passphrases and do not truncate or block paste.

What Does Not Work Against Credential Stuffing

Account lockout alone, since one attempt per account never trips it.

IP blocklists, defeated by residential proxy rotation.

CAPTCHA as a sole control, routinely outsourced to solving services.

Security questions, whose answers are often in the same breach dumps.

Complexity rules without breach screening, which produce `Password1!` at scale.

Detecting an Attack in Progress

Watch for these patterns:

A sharp rise in login volume with an unusually low success rate.

Failed logins spread thinly across a very large number of distinct accounts.

A geographic distribution of login sources that does not match your user base.

Many accounts authenticating from the same handful of device fingerprints.

A surge in password reset requests.

Support tickets clustering around "I’m locked out" or "I didn’t do that".

The last one matters. Users often detect credential stuffing before monitoring does, which is why an easy reporting path pays for itself.

Set the alerting threshold on the *ratio* rather than the volume. A credential stuffing run against a busy service can be invisible in absolute login counts while being obvious in the success-to-failure ratio.

Incident Response When Credential Stuffing Succeeds

Confirm scope. Identify which accounts authenticated successfully from suspect sources.

Force reset on confirmed and suspected accounts, invalidating existing sessions and refresh tokens.

Revoke tokens and API keys tied to affected accounts — a password reset alone does not kill a live session.

Enforce MFA enrolment on reset for any account that lacked it.

Check for persistence. Attackers add MFA devices, mail forwarding rules, OAuth grants, and recovery addresses.

Review what was accessed during the window, not just how entry occurred.

Notify affected users and, where obligations apply, regulators.

Screen the wider estate for the same credential pairs.

Point five is the one most commonly skipped. An attacker who registers their own MFA device retains access through every password reset that follows.

Conclusion

Credential stuffing is not a sophisticated attack. It is an economic one, and it succeeds because password reuse is a human default rather than a technical flaw.

The controls that matter are unglamorous: MFA everywhere with phishing-resistant factors, screening against breached password sets, bot detection that reads behaviour, and monitoring tuned to the failed-then-successful login pattern.

The rest is habit. Unique credentials per account, generated and stored by a password manager, remove the raw material the attack depends on. Our cyber security tips guide covers that baseline, and you can see our wider approach on the CyberX home page.

Build the Password Habit That Removes the Fuel — LMS-X

Every technical control against credential stuffing is compensating for one behaviour: the same password used in two places.

LMS-X lets you build structured, role-based learning paths covering password hygiene, MFA behaviour, and account security — with assessment and completion records you can produce for an auditor, and knowledge checks that show whether the message landed.

Contact us to design a learning path that targets the habits behind your most likely account-takeover route.

Frequently Asked Questions

How is credential stuffing different from a data breach?

A breach is how the credentials were originally exposed, usually at some other organisation. Credential stuffing is the follow-on attack that reuses them against you. Your systems can be fully patched and still be compromised this way.

Does MFA completely stop credential stuffing?

It stops the overwhelming majority of attempts, because a valid password alone no longer grants access. Gaps remain where MFA coverage is incomplete, where legacy protocols bypass it, or where push-fatigue and real-time phishing proxies defeat weaker factors.

How do I know if my credentials are in a breach?

Reputable breach-notification services let you check an email address against known dumps. At an organisational level, breached-credential screening at login and password change is the systematic version of the same check.

Are password managers safe given they hold everything?

The concentration risk is real but favourable on balance: a password manager makes unique credentials for every account practical, which removes the reuse that credential stuffing depends on. Protect it with a strong master passphrase and MFA.

How often should employees change passwords?

Current authentication guidance favours changing passwords on evidence of compromise rather than on a fixed schedule. Forced rotation tends to produce predictable variations that offer little additional protection.