Credential stuffing shows up throughout this site's other password posts as the reason a given defense matters — breach-checking exists because of it, rate limiting exists partly because of it, Passwords vs Passkeys mentions it in passing as an attack passkeys close entirely — but it's never been the subject of its own post. This is that piece: what the attack actually is, why it works at the scale it does, and what specifically stops it.
What credential stuffing actually is
Credential stuffing is trying already-leaked username/password pairs from one breach against other, unrelated sites — automated, at scale, across millions of accounts at once. It's not guessing. The attacker already has a working password; the only open question is whether the same person reused it somewhere else. Given how often people do, the answer is yes often enough to make the attack profitable even at a low success rate.
This is a different attack from a brute-force attempt, which tries many candidate passwords against one account, or an offline cracking attempt, which tries candidates against a stolen password hash with no server involved at all. Credential stuffing tries one real, already-correct password per account against a login form it's never been used on before. It doesn't need to guess anything — it needs the target account to share a password with an account that already leaked somewhere else.
Why it works at scale: password reuse
The entire attack depends on one human behavior: reusing a password, or a close variant of one, across multiple accounts. Security research has repeatedly found reuse rates in the range of 50-65% among internet users — meaning a password leaked from one breached site has a real chance of unlocking accounts on sites that were never breached at all. Multiply that by breach corpora containing billions of leaked credential pairs, and even a success rate well under one percent per attempt produces a large absolute number of compromised accounts.
This is also why credential stuffing is arguably the most consequential password attack in practice, ahead of both brute-forcing and offline cracking — it doesn't require breaking any cryptography or defeating any rate limit meaningfully faster than a real user logs in. It just requires that reuse happened somewhere, which at internet scale is close to guaranteed for any sufficiently large user base.
How the attack actually runs
- The credential list. Billions of leaked username/email + password pairs circulate from past breaches, compiled into combolists traded and sold on criminal forums. The attacker doesn't need to breach the target site at all — the raw material comes from breaches of completely different services.
- Automated login attempts. Purpose-built credential-stuffing tools (Sentry MBA and OpenBullet are two names that show up repeatedly in incident reports) submit the list against a target's login endpoint automatically, tracking which pairs succeed.
- Distributed, human-looking traffic. Attempts get spread across large proxy networks and residential IP pools specifically to avoid the simplest defense — an IP address making too many login attempts — and to blend in with normal traffic patterns rather than looking like a single script.
- Low per-attempt success, high absolute yield. Success rates on individual attempts are typically well under 1% — but tested against millions of accounts, that still yields a large number of working logins, at a cost per attempt low enough to make the economics work.
What a successful hit is worth
A compromised account isn't usually the end goal — it's inventory. Confirmed working pairs get resold, drained directly (stored payment methods, loyalty points, gift card balances), or used as a foothold for further fraud. Account takeover at this volume is a commodity criminal business with its own supply chain, which is part of why the defenses below are standard security practice rather than an edge case worth ignoring.
What actually stops it
- Breach-checking at password creation and login. Rejecting (or forcing a reset on) a password that appears in a known breach corpus — the exact NIST SP 800-63B requirement NIST Password Guidelines Explained covers — removes the specific pairs an attacker is most likely to already have. It's the single defense most directly aimed at this attack, since it targets the reuse itself rather than anything downstream of it.
- MFA. A correct password stops mattering the moment a second, independent factor is required — Multi-Factor Authentication Explained covers why this holds even against an attacker who has the exact right password, not just a guessed one.
- Passkeys, structurally. Credential stuffing depends on a password being a shared secret that can be typed into more than one site. A passkey is never shared and never typed anywhere — as Passwords vs Passkeys puts it, there's no value to reuse, because one was never generated to be reused in the first place. This is the one defense that closes the attack by construction rather than by catching it after the fact.
- Rate limiting and lockout. Caps how many login attempts an account or source can make in a window, graded by Password Storage Checker alongside hashing and breach-checking. It helps, but distributed proxy traffic specifically exists to blunt this defense by keeping per-IP volume low, so it's a layer, not a solution on its own.
- Bot detection and device/behavioral signals. CAPTCHAs, device fingerprinting, and anomaly detection (login velocity, impossible-travel checks, known-bad proxy ranges) target the automation itself rather than the credentials — useful precisely because the other defenses above don't see the traffic pattern at all.
None of these fully substitute for another — breach-checking closes off the specific credentials attackers already hold, MFA and passkeys make a correct password insufficient on its own, and rate limiting plus bot detection slow down the automation itself. A system relying on just one is still exposed to whichever attack path that one doesn't cover.
Common mistakes
- Treating it as a brute-force problem. Brute-force defenses (longer passwords, composition rules) do almost nothing here — the attacker isn't guessing, they already have a correct password. The fix is breach-checking and MFA, not a stronger length requirement.
- Relying on IP-based rate limiting alone. Distributed proxy and residential IP traffic is specifically built to defeat exactly this defense by keeping attempts-per-IP low. It still helps against unsophisticated attempts, but it's not sufficient by itself against a real credential-stuffing operation.
- Only checking breach status at password creation. A password that was fine when created can appear in a new breach corpus later — ongoing or periodic re-checking against an updated corpus catches accounts a one-time check at signup would miss.
- Assuming this only matters for large, high-profile sites. Automated tools don't discriminate by target size — any site with a login form and a real user base is in scope, since the attacker's cost per target is close to zero regardless of who the target is.
FAQ
Is credential stuffing the same as a brute-force attack?
No. Brute-force tries many candidate passwords against one account. Credential stuffing tries one already-correct password — leaked from an unrelated breach — against accounts that might share it. The defenses that help against one largely don't help against the other.
Does a strong, long password protect against credential stuffing?
Only indirectly, by making the password less likely to have been guessed elsewhere in the first place — but a strong password that's reused is exactly as vulnerable as a weak one that's reused, once it appears in a breach corpus. Uniqueness matters here far more than strength; see Minimum Password Length Recommendations for where length actually does and doesn't help.
How would I know if my organization is being targeted?
A spike in failed logins distributed across many source IPs, an unusual ratio of failed to successful logins on accounts that normally log in without issue, or login attempts against usernames/emails that don't exist in your system (testing a combolist blind) are common early signals.
Do CAPTCHAs solve this?
They raise the cost meaningfully but don't solve it outright — CAPTCHA-solving services and increasingly capable automated solvers exist specifically because the economics of credential stuffing can absorb that added cost. It's one layer among several, not a standalone fix.
Try it yourself
Password Storage Checker grades whether a system actually enforces breach-checking, MFA, and rate limiting — the three defenses most directly aimed at this attack — alongside its hashing practices. Runs entirely in your browser. See Password Security: A Comprehensive Guide for how this fits the other layers of password security.