There are currently over 15 billion compromised username and password pairs available on criminal marketplaces and darknet forums. Every major breach — RockYou2024, the LinkedIn breach, the Dropbox leak, thousands of smaller incidents — contributes to a growing corpus of real-world credentials that attackers use not just against the breached service, but against every other service where the same user might have reused the same password. Credential stuffing turns this repository into an automated, scalable attack pipeline. It is one of the highest-volume attack types against web applications, and its defenses require a more nuanced response than simply enforcing MFA.
TL;DR: Credential stuffing uses real breached credentials to attempt logins at scale — exploiting password reuse across services. Success rates of 0.1–2% against billions of pairs mean thousands of compromised accounts. Standard rate limiting fails against distributed attacks. Effective defense requires bot detection, FIDO2 MFA, breached credential checking, and anomalous login alerting — validated through penetration testing of your authentication implementation.
How Credential Stuffing Works
The attack lifecycle has three phases that are now almost entirely automated:
Phase 1: Credential acquisition
Attackers purchase or download breach datasets from criminal marketplaces. The largest collections — aggregated from thousands of individual breaches — contain billions of unique email/password and username/password pairs. These are sold as formatted combo lists sorted by email domain, allowing attackers to target users of a specific service more efficiently. Some specialized tools automatically deduplicate and validate credentials against known-valid formats before a stuffing campaign even begins.
Phase 2: Automated stuffing
Dedicated credential stuffing tools — OpenBullet, SilverBullet, and custom-built frameworks — load combo lists and execute login attempts at high speed. Modern stuffing infrastructure uses residential proxy networks (IP addresses belonging to legitimate consumer ISPs, rented from unwitting device owners via malware) to make each login attempt appear to originate from a different, legitimate-looking location. This defeats simple IP-based rate limiting: the traffic looks like thousands of different users from legitimate residential connections, not a single attacker.
Success rates vary by target and combo list quality, but 0.1–2% is typical against consumer services. Against a list of 10 million credentials, that is 10,000–200,000 successful account takeovers from a single campaign.
Phase 3: Account exploitation
Compromised accounts are monetized immediately or sold. High-value accounts — those with stored payment methods, loyalty points, corporate access, or sensitive data — command premium prices. For SaaS applications, a compromised account may provide access to sensitive customer data, enabling downstream fraud, data exfiltration, or pivoting into the organization's internal systems if the compromised account belongs to an employee or administrator.
Why Standard Rate Limiting Fails
The naive defense against credential stuffing is rate limiting — block an IP that makes too many failed login attempts. Modern credential stuffing attacks are specifically designed to defeat this control:
- Residential proxy networks distribute attempts across thousands of unique IPs, each making only one or two requests before rotating. A rate limit of 10 attempts per IP per hour is irrelevant when each IP only makes one attempt.
- Slow-and-low timing spreads requests across hours or days, avoiding volume-based anomaly detection thresholds.
- Valid user agent rotation mimics real browser fingerprints, including TLS fingerprints that simple bot detection checks.
- CAPTCHA solving services use human solvers (paid pennies per CAPTCHA) or ML-based automated solving to defeat challenge-response controls.
This is why effective credential stuffing defense requires bot detection at a signal level that is genuinely difficult to fake — behavioral biometrics, device fingerprinting, JavaScript execution analysis, and TLS fingerprint analysis — rather than simple IP-based or rate-based rules.
The MFA Question
MFA is the most commonly cited defense against credential stuffing, and it does dramatically reduce the attack surface. But the effectiveness of MFA depends entirely on the type deployed:
| MFA Type | Credential Stuffing Resistance | Attack Method |
|---|---|---|
| SMS OTP | Low-Medium | SIM swapping, SS7 interception, real-time phishing proxies relay OTP before expiry |
| TOTP (Authenticator app) | Medium | Real-time phishing proxies (Evilginx, Modlishka) relay valid TOTP before 30-second window expires |
| Push notification (Duo/MS Auth) | Medium | MFA fatigue — repeated push requests until user approves; social engineering calls claiming to be IT |
| FIDO2 / WebAuthn hardware key | Very High | No known practical attack — authentication is cryptographically bound to the legitimate origin domain, defeating phishing proxies |
| Passkeys (device-bound FIDO2) | Very High | Same as hardware FIDO2 — origin-bound; phishing proxies cannot relay the authentication challenge |
The conclusion is uncomfortable but clear: SMS and TOTP-based MFA meaningfully raise the cost of account takeover but do not stop sophisticated real-time phishing proxy attacks. If you are protecting high-value accounts — financial services, enterprise SaaS with data access, admin accounts — the only authentication mechanism that reliably defeats credential stuffing plus phishing is FIDO2/WebAuthn.
Effective Defenses
Breached credential checking at registration and login
Check passwords against known-breached credential databases at the point of account creation and on each login. Have I Been Pwned (HIBP) provides a free k-anonymity API that allows you to check whether a password appears in known breach datasets without exposing the full password to the API. Reject passwords that appear in breach lists and prompt users who have reused previously-breached passwords to change them. This proactively shrinks your exploitable credential surface before attackers find it.
Bot management beyond basic rate limiting
Purpose-built bot management platforms (Cloudflare Bot Management, Imperva, DataDome, Arkose Labs) analyze dozens of signals simultaneously to distinguish human from automated traffic — JavaScript execution behavior, device fingerprinting, TLS client hello fingerprints, mouse movement patterns, typing cadence, and behavioral anomalies across the session. These signals are significantly harder to fake than IP address alone. For applications handling sensitive data or high-value accounts, dedicated bot management is worth the investment.
Anomalous login alerting for users
Notify users immediately when a login occurs from an unrecognized device, new geographic location, or unusual time. Give them a clear one-click mechanism to deny the session and trigger a password reset. This does not prevent the initial compromise but catches it before significant damage occurs and builds user trust in your security posture. Many credential stuffing-enabled account takeovers go undetected for weeks because users are not notified of the suspicious login.
Test your authentication implementation
A web application penetration test against your authentication layer specifically tests whether your rate limiting, bot detection, and MFA implementation hold up against realistic credential stuffing simulation. Pentesters regularly find rate limiting that only applies to failed attempts (not distributed across IPs), MFA implementations that can be bypassed by replaying session tokens, and breached credential checks that can be circumvented through minor password variation. These are findings you want to know about before attackers discover them.
Business Impact and Liability
Beyond the direct impact of compromised accounts, credential stuffing creates business risk in several dimensions that security and legal teams need to understand:
- Data breach notification obligations. If stuffed credentials result in unauthorized access to personal data, you may have GDPR Article 33 (72-hour notification), CCPA, or state breach notification obligations — even though the initial credential breach occurred at another organization.
- Regulatory exposure in financial services. For fintech and banking applications, account takeover via credential stuffing triggers regulatory scrutiny around authentication controls and AML obligations if compromised accounts are used for fraudulent transactions.
- Reputational damage. Users whose accounts are taken over through password reuse at your application will blame your platform, regardless of where the original credentials were stolen. Your customer communications and public handling of ATO incidents directly affect brand trust.
- Enterprise customer liability. If your application is used by enterprise customers and a credential stuffing attack compromises employee accounts, those customers may hold you liable under contractual security warranties in your MSA.
Is your authentication layer ready for credential stuffing attacks?
Lorikeet Security's web application penetration testing includes dedicated authentication testing — rate limiting validation, MFA bypass testing, and credential stuffing simulation against your real login flows.
