What Is Credential Stuffing? Attacks and Defenses Explained

Credential stuffing is an attack where an adversary takes username-and-password pairs leaked from one breach and tries them, automatically and at scale, against logins on unrelated sites. It works because so many people reuse the same password across services — a breach at one company can hand attackers working logins for millions of accounts elsewhere, even if the second site was never itself compromised.

Why it works: password reuse

The attack doesn’t guess passwords; it replays real ones. Data breaches routinely expose millions of email-password pairs, and those dumps circulate widely. If a user reused a password across a breached site and your site, an attacker doesn’t need to crack anything — they already have valid credentials, they just don’t know which sites they work on. Credential stuffing is the automated process of finding out, by firing the same pair at login endpoints across the web using bot tooling that mimics normal browser traffic.

This is fundamentally different from a brute-force attack, which tries many password guesses against one specific account. Credential stuffing tries one known-good pair per account across many accounts and many sites — the attacker isn’t guessing, they’re checking which doors a known key also happens to open.

What a successful attempt looks like from the outside

At scale, credential stuffing produces a distinctive pattern: a burst of login attempts, often from a wide spread of IP addresses (to evade simple rate limits), each attempt using a different username but often reusing infrastructure signatures — consistent request timing, identical browser fingerprints, or traffic through known proxy/VPN pools. Success rates are typically low, often well under 1%, but at the scale of a breach with millions of credentials, even a fraction of a percent yields a meaningful number of compromised accounts. Attackers then use those accounts directly, or sell verified working logins, which are more valuable than raw unverified breach data.

Defenses that actually work

Multi-factor authentication is the single most effective defense — see what MFA is for the mechanics. Even a perfectly valid stolen password fails if the attacker doesn’t also control the second factor. Sites that support passkeys go further: there’s no reusable password to steal from anywhere in the first place.

Rate limiting and anomaly detection slow down or block the automated attempts before they exhaust a credential list. Effective rate limiting for login endpoints usually needs to account for distributed attempts (many IPs, few attempts each) rather than just capping requests per IP — otherwise a slow, distributed stuffing attempt slides right under a naive threshold. This is a good use case for a dedicated WAF or bot-management layer sitting in front of the login endpoint.

Breach-aware password checks. Some services check new passwords against known-breached-password lists at signup or login and reject or flag matches, closing the loop before reuse becomes exploitable in the first place.

CAPTCHA and device fingerprinting raise the cost of automation, though sophisticated attackers increasingly route through CAPTCHA-solving services or residential proxy pools, so these work best as one layer among several rather than a sole defense.

Defense in depth: a comparison

Defense	What it stops	Limitation
MFA	Login even with a valid stolen password	Requires user adoption; SMS-based MFA has its own weaknesses
Passkeys	Password theft entirely	Requires platform/browser support
Rate limiting	High-volume attempts from a given source	Distributed attacks can evade naive per-IP limits
Breach-password checks	Reuse of already-exposed passwords	Doesn’t stop credentials not yet in known breach lists
CAPTCHA / bot detection	Naive automation	Can be defeated by sophisticated tooling

No single control is sufficient on its own; the practical answer is layering several of these so that defeating one doesn’t defeat the login flow entirely.

What individuals can do

The user-side fix is the same root cause as the attack: stop reusing passwords. A password manager generating a unique, random password per site means a breach elsewhere never yields a working credential on your other accounts. Enabling MFA everywhere it’s offered adds a second layer that a stolen password alone can’t cross. This is a case where the hashing an operator applies to your stored password — bcrypt or Argon2 — doesn’t help you at all if you reused that same password on a site that got breached and stored it insecurely, or even securely but the attacker still obtained the plaintext through some other route (phishing, malware) before it was ever hashed.

The takeaway

Credential stuffing doesn’t crack passwords — it replays real ones stolen elsewhere, betting on the fact that people reuse them. The defense that ends the attack outright is removing the reusable secret: MFA makes a valid password insufficient on its own, and passkeys remove the password entirely. Rate limiting, bot detection, and breach-password checks are useful supporting layers, but none of them substitute for making stolen credentials worthless in the first place.