Credential Stuffing: Why Rate Limits Are Not a Defence

Q: What is credential stuffing and how is it different from brute force?

Credential stuffing is the automated replay of username and password pairs stolen from one service against the login of a different, unrelated service, betting on the fact that a large fraction of people reuse the same password across sites. It is fundamentally different from brute force. A brute-force or password-spraying attack guesses passwords against an account, generating many failed attempts per account from a small number of sources. Credential stuffing does the opposite: it tries exactly one or two already-known-valid passwords against each of millions of accounts, a behaviour that is wide rather than deep. That shape is why the defences differ. Per-account lockout thresholds and per-IP rate limits are tuned for the deep, noisy pattern of brute force and are structurally blind to the wide, quiet pattern of stuffing, where each individual account sees a single attempt and each individual IP in a residential-proxy pool sees only a handful. The credentials themselves usually come from combo lists aggregated from prior breaches and, increasingly, from infostealer malware logs, which is why a fresh breach elsewhere shows up as a stuffing wave against you within days.

Q: Why do per-IP rate limits fail against credential stuffing?

Per-IP rate limits fail because the attack is deliberately distributed to stay under them. A credential-stuffing operator routes traffic through a residential-proxy pool of tens of thousands of IP addresses, each of which looks exactly like a real customer on a real home broadband connection, and sends only one or two login attempts through any single address. From the perspective of your rate limiter, which counts attempts per IP over a time window, every one of those addresses is behaving like a normal user and none of them crosses the threshold that would trigger a block or a challenge. The aggregate might be forty thousand attempts against your login in an hour, but it arrives as two attempts from each of twenty thousand addresses, and the limiter has no concept of the aggregate. The economics make this cheap for the attacker: residential-proxy bandwidth is sold by the gigabyte and the marginal cost of spreading across more IPs is negligible. This is why rate limiting belongs in the category of table stakes — worth having, useless as a primary defence — and why real programs move the unit of measurement from the IP address to the client and the population-level pattern.

Q: What actually stops credential stuffing?

Only one control ends credential stuffing as a category rather than merely slowing it: removing the shared secret by moving to phishing-resistant credentials such as passkeys built on the WebAuthn standard, because a private key bound to the device and origin has nothing that can be leaked on another site and replayed against yours. Short of that terminal state, the effective controls work by changing the attacker’s economics rather than trying to block individual attempts. Screening every new and reset password against a corpus of known-breached passwords shrinks the fraction of the attacker’s list that will ever work, so the attack is less profitable before it begins. Device and behavioural signalling scores the client rather than the IP, raising the cost of each attempt by forcing the attacker to defeat fingerprinting and integrity checks. Risk-based step-up authentication then places a challenge — MFA, email verification, a passkey prompt — only on anomalous logins, which blocks the attacker’s payoff without taxing the overwhelming majority of honest users who log in from a recognised device. OWASP and Microsoft both rank multi-factor authentication as the single highest-leverage control, with analysis suggesting MFA alone would have stopped around 99.9% of account compromises.

Q: Is CAPTCHA a good defence against credential stuffing?

CAPTCHA is a poor front-line defence and a reasonable last resort reserved for high-risk cases. The core problem is that a CAPTCHA on every login imposes friction on one hundred percent of your honest users in order to inconvenience an attacker who can defeat it cheaply. Commercial CAPTCHA-solving services, some human-powered and increasingly many automated, clear puzzles at a price on the order of a dollar per thousand solves, which is trivial against the value of a successfully taken-over account, and modern automated solvers handle many CAPTCHA types outright. So the control that annoys every real customer barely dents the attacker’s cost model. The defensible use of a CAPTCHA or a similar interactive challenge is targeted: present it only when a risk engine has already scored a login attempt as suspicious based on device, velocity, or population signals, so that honest users almost never see it and the challenge is applied precisely where it raises cost for automation. Used that way it is one tool in a risk-based step-up ladder; used as a blanket gate on the login page it is mostly a tax on conversion that provides a false sense of security.

Q: Should we force users to change passwords periodically to prevent stuffing?

No. Mandatory periodic password rotation is explicitly advised against by NIST SP 800-63B, and it does essentially nothing against credential stuffing while making your passwords weaker on average. The behavioural evidence that drove NIST to drop the recommendation is consistent: when users are forced to change passwords on a schedule, they respond predictably by choosing weaker passwords and by making small, guessable increments to an existing one, such as appending a month or a digit, which undermines the very strength rotation was supposed to preserve. Against stuffing specifically, rotation is beside the point, because the attacker is using a password that is valid right now; a rotation policy that fires every ninety days does not help when the compromised credential is being replayed today. The guidance that actually reduces stuffing risk is the opposite posture: do not expire passwords on a timer, screen proposed passwords against breach corpora at the moment they are set or reset so a known-compromised value is never accepted, and force a change only when there is specific evidence that a credential has been compromised. That combination keeps strong passwords in place longer and removes the reused, breached ones that stuffing depends on.

Q: What signals detect a credential-stuffing attack if not the IP address?

The signals that survive a residential-proxy pool all share one property: they describe the client and the population rather than the network address. Device fingerprint and device integrity come first — a consistent, attestable device is cheap to trust, while automation tells such as a missing GPU, impossible event timing, or uniform TLS fingerprints across many supposed users flag a bot without ever inconveniencing a genuine customer. The second and most diagnostic signal is velocity measured across accounts rather than within one account: credential stuffing is wide, so the fingerprint of an attack is a fan-out of many distinct accounts failing authentication from a set of correlated clients, a pattern that per-account counters cannot see by construction. The third is population-level anomaly detection — a sudden shift in your global login-failure rate, a change in the geographic or autonomous-system-number mix of your traffic, or a spike in the ratio of new or unrecognised devices. These aggregate signals are the true signature of an attack in progress, which is why a login endpoint deserves the same first-class real-time instrumentation you would give any critical system, not to block per IP but to see the whole picture and feed a risk engine that can challenge precisely the anomalous attempts.

Q: How does credential stuffing relate to account takeover and session theft?

Credential stuffing is one entry path into the broader problem of account takeover, and it sits at the front of a chain that continues well past the login form, which is why the controls need to be designed together rather than as a single oversized login check. A successful stuffing hit gives the attacker valid credentials; account takeover is what they do with them, and a mature defence treats authentication and post-authentication as two distinct control surfaces. Even if a stuffed credential slips through the login-time risk scoring, a well-designed system continues to evaluate session risk after login — watching for a sudden change in device, location, or behaviour, and re-challenging or terminating the session when the post-login signals diverge from the user’s norm. Stolen session tokens are a parallel path that bypasses the password entirely, harvested by infostealer malware and replayed, which is why token-binding and proof-of-possession defences matter alongside credential-stuffing controls. The correct mental model is a layered one: breached-password screening and passkeys reduce what can be stuffed at the front, risk-based step-up blocks the anomalous login, and continuous session-risk monitoring plus token-binding catch the attacker who gets past the door or skips it.

Q: When is it worth building a full risk-based authentication engine versus buying one?

The decision hinges on whether authentication risk is a core part of your product surface and on whether you can close the feedback loop that makes a risk engine improve rather than decay. A risk engine that scores device, velocity, and population signals but never learns which of its challenges actually caught a confirmed account takeover degrades into noise: its thresholds drift, its false-positive rate climbs, and honest users get challenged for no gain. The single most important input to a durable program is therefore the confirmed-fraud or confirmed-ATO outcome fed back into the model, the same discipline that makes deepfake-resistant KYC and card-fraud scoring work. For most organisations, a specialist bot-mitigation or fraud vendor supplies better device and network intelligence than you could assemble alone, because they see attack patterns across many customers, and buying that signal while retaining control of the step-up policy and the outcome feedback is the pragmatic middle path. Building the whole stack in-house is justified when login and fraud are central to your economics — a large consumer marketplace, a financial service, a payments platform — where the scale makes the fixed engineering cost worth it and where proprietary outcome data is a genuine advantage. Either way, the non-negotiable is the feedback loop; a risk engine without it is a one-time configuration that silently rots.

Satyam Kumar

Retour au blog

cyber-security-patterns

Credential Stuffing at Scale: Rate Limits Are Not a Defence (2026)

By Satyam KumarSeptember 12, 202610 min read

credential stuffing account takeover account takeover defence password reuse residential proxies bot mitigation device fingerprinting risk-based authentication adaptive mfa passkeys webauthn breached password check owasp credential stuffing nist sp 800-63b identity and access management credential stuffing 2026

Credential Stuffing at Scale: Rate Limits Are Not a Defence (2026)

Frequently Asked Questions

Partager l'article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Architecte AI & Cloud. J'aide les équipes à construire des systèmes qui scalent pour des millions.

LinkedIn GitHub

Credential Stuffing at Scale: Rate Limits Are Not a Defence (2026)

Frequently Asked Questions

Partager l'article

Comments

Leave a comment