What Is Credential Stuffing?

The attack does not guess anything

Credential stuffing takes username and password pairs that leaked from one service and replays them against another.

Nothing is generated. No dictionary is consulted. The attacker holds pairs that are known to have worked somewhere, and is testing whether the person reused them. That single property separates it from every other password attack and determines which defences apply.

Four attacks are routinely confused, and the differences matter:

Brute force generates candidate passwords and tries them against one account until something works. Rate limiting and lockout stop it.

Dictionary attack narrows the candidate space to likely passwords rather than all possible ones. Same shape, same defences.

Password spraying tries a small number of very common passwords across many accounts, staying below lockout thresholds deliberately.

Credential stuffing tries known valid pairs across many accounts. It resembles spraying in shape and brute force in that the password is specific to the account, which is what makes it more effective than either.

Why the standard defences miss it

Account lockout was designed against repeated attempts on a single account. Credential stuffing generates one attempt per account across a very large number of accounts. No threshold is approached, no lockout fires, and the security team's dashboard shows a modest uptick in failed logins.

Per account rate limiting fails for exactly the same reason.

This is why organisations with genuinely sound brute force protection still lose accounts. The control is working as designed against an attack of a different shape.

The economics are the whole story

The reason this persists is not technical sophistication. It is cost.

An attacker needs three things. A list of pairs, which is frequently free, since combolists circulate at no charge as advertising for fresher paid data. Configuration driven tooling, which is cheap and widely available, requiring no development skill. And residential proxy bandwidth, which as of September 2026 runs at roughly one dollar per gigabyte.

That last figure is the important one. A login request is small. At one dollar per gigabyte, the bandwidth cost of a single authentication attempt is a fraction of a cent.

Work through what that means. Even at a success rate low enough that most people would call the attack a failure, the arithmetic works, because the denominator can be made arbitrarily large for almost nothing. The attack does not need to be efficient. It needs to be cheap, and it is.

On the success rate figure

You will see a claim that credential stuffing succeeds on between 0.1 and 2 percent of attempts. It is quoted constantly, including by vendors who should know better.

We looked for its source. It traces to a 2019 post by an engineer at a bot management company, citing internal telemetry that was never published. The dataset, the sampling frame, and the definition of a success were not disclosed. The 0.1 percent lower bound appears to have entered circulation through retelling rather than from the original.

Worse, at least four incompatible definitions of "success" are in use across sources that quote a rate: a valid credential pair, a completed login, a login that survived subsequent fraud checks, and a login that produced financial loss. Those produce wildly different numbers from the same data.

We are not offering a replacement figure, because we do not have one worth defending. The honest position is that the success rate is low, the cost is lower, and the ratio is what matters rather than either number alone.

Password reuse is the dependency

The entire attack rests on people reusing passwords. Two pieces of evidence are worth having.

Browser instrumented research presented at ACM CCS in 2017, following 154 participants over an average of 147 days, found that around 60 percent of passwords were partially or exactly reused, with 32 percent reused exactly across an average of six domains.

More recently, Cloudflare telemetry covering September to November 2024, published in March 2025, found that 41 percent of successful logins used a password present in a known breach corpus, and that 95 percent of login attempts using leaked passwords came from bots rather than humans.

The partial reuse figure deserves attention, because it creates a gap in the standard defence. Screening against breach corpora catches exact matches. Someone who changed one character is not caught, and roughly half the reusing population does exactly that.

What detection actually looks like

Any single credential stuffing request is indistinguishable from a legitimate login. Correct format, plausible credentials, residential source address. Nothing to flag.

The signal is distributional rather than individual:

An unusual ratio of failures to successes measured across the whole authentication surface rather than per account.

Concentration in source characteristics that are not the IP address, since that rotates. Autonomous system, TLS fingerprint, header ordering, device fingerprint.

Timing regularity that does not resemble human behaviour, though sophisticated tooling randomises this.

Geographic distribution inconsistent with the service's normal user base.

Detecting this requires aggregate analysis across the authentication surface. Many authentication stacks do not perform it by default, which is a large part of why the attack remains viable.

Controls, in order of effect

Multi factor authentication. It does not prevent the attempt, it prevents the attempt from succeeding, which for this attack class is decisive. The limitation is specific: it does not address stolen session cookies, which represent an authentication already completed. HP Wolf Security reported in December 2025 that token theft made up 31 percent of observed Microsoft 365 MFA bypasses.

Screen against known compromised passwords. NIST SP 800-63B Revision 4, published 26 August 2025, now requires verifiers to check candidate passwords against corpora of known compromised values, at registration and at change. This removes the reuse the attack depends on, at the moment the decision is made rather than after. The same revision states that composition rules and periodic forced rotation SHALL NOT be imposed, reversing decades of common practice.

Rate limit on source characteristics, not accounts. Since the attack spreads across accounts, per account limits never fire. Limits need to key on something the attacker cannot rotate cheaply.

Monitor for your own exposure. Internal telemetry shows you failed logins. It does not tell you that credentials for your domain are in circulation and about to be used. That signal is external, and it arrives before the attack rather than during it. See stealer log monitoring.

For individuals, the attack is fully defeated by non reuse. A unique password per service reduces a leaked pair to one compromised account rather than a key to everything.

Where the credentials come from

Credential stuffing is a consumer of data produced elsewhere. Two pipelines feed it.

Breach corpora, where a service was compromised and its authentication database extracted, then cracked where the hashing permitted.

Infostealer malware, which harvests credentials directly from infected devices. This source has grown to represent a substantial share of newly circulating material, and it produces fresher data than breach corpora do, because there is no gap between compromise and extraction.

Both end up stripped of context and aggregated into the combolists that feed the tooling. Which is why the useful question for a defender is not whether you are being attacked, but whether your credentials are already in circulation.