Credential Stuffing: What It Is and How to Stop It

What is credential stuffing?

Credential stuffing is an attack in which bots take username and password pairs leaked from one website and try them on the login form of another. It works because people reuse passwords. Anyone who used the same email address and password at a breached online shop and at your service has handed the attacker a working login to your service.

You will also see it written “credentials stuffing”. It is the same attack, and the name describes it well: stolen credentials get stuffed into someone else’s login form at bot speed until some of them work.

The attacker does not guess anything. Every pair on the list belonged to a real account somewhere. Most of them fail on your site, because the person never had an account with you or chose a different password. That hardly matters to the attacker. The lists are long, the attempts cost next to nothing, and a small share of hits is enough to make the run pay.

What the working accounts are good for depends on your business: stored payment methods, loyalty points and gift card balances, personal data for phishing, or simply accounts to resell. On a SaaS product, one taken-over account can expose a customer’s whole workspace. Credential stuffing is the automated route to account takeover, and our page on account takeover protection covers the wider set of controls.

How a credential stuffing attack works

A credential stuffing attack has four stages, and only one of them happens on your side.

1. A leaked list. Email addresses or usernames with their passwords, collected from data breaches, phishing pages and malware that steals passwords saved in browsers. They circulate as “combo lists”, often merged from many breaches and sold or shared for free.
2. A tool with a config for your site. The attacker loads the list into an automation tool and adds a config for your login: which URL to call, which fields to fill, what a successful login looks like. Configs for popular sites get traded just like the lists.
3. Bots spread the attempts. The tool sends the logins through large proxy pools, often residential IP addresses, so each address sends only a few requests and each account is tried once or twice. To your server it looks like many unrelated visitors who each mistyped a password.
4. Hits become takeovers. Logins that work are saved, checked for value and then used, sold or locked by changing the email address and password before the owner notices.

You cannot recall a leaked list, and you have no say in where your users reuse their passwords. Stage three is where you have a say. Every pair on the list has to pass through your login form or your login API, and that is where you can make each attempt expensive.

Credential stuffing vs brute force

In a brute force attack, the attacker does not know the password and guesses, usually many passwords against one account. In credential stuffing, the attacker already holds a password that someone really used and tries it once on the matching account. That difference decides which defenses work.

Account lockout is the classic answer to brute force: after a number of failed attempts, the account is locked or slowed down. Against credential stuffing it does almost nothing, because each account sees one or two attempts. NIST’s password guideline SP 800-63B asks services to allow no more than 100 consecutive failed attempts on one account. A credential stuffing run never comes close to that number on any single account.

Password spraying sits between the two: a handful of common passwords tried against many accounts. The OWASP Credential Stuffing Prevention Cheat Sheet treats the three as related attacks and notes that most defenses work against all of them.

For the guessing attacks, our guide to brute force protection covers lockouts, delays and where a CAPTCHA fits.

How to spot credential stuffing

A run that is spread over thousands of IP addresses rarely trips a single alarm. It shows up in the totals:

• Failed logins rise across many accounts at once, while the count per account stays low.
• A high share of attempts uses email addresses that have no account with you at all. Real users rarely type an address you have never seen.
• Logins come from networks you rarely see: hosting providers, proxy services, countries where you have no customers.
• One IP address or one device fingerprint tries many different accounts, or the requests arrive at suspiciously even intervals.
• Requests skip parts of a normal visit: no page assets loaded, missing headers, traces of a headless browser, direct calls to the login API.
• Afterwards: a wave of password resets, changed email addresses and support tickets about orders nobody placed.

How to prevent credential stuffing

No single control stops credential stuffing. Four of them together do most of the work: multi-factor authentication, so a stolen password alone is not enough; breached-password checks, so the passwords on attackers’ lists stop working; rate limits that look beyond the IP address; and bot detection on the login form, so every automated attempt costs something. The OWASP cheat sheet linked above describes the same building blocks in more depth.

Multi-factor authentication

OWASP calls MFA “by far the best defense against the majority of password-related attacks” and cites a Microsoft analysis that found it would have stopped 99.9% of account compromises. With a second factor, a correct password from a leaked list no longer opens the account.

MFA has gaps all the same. It protects only the accounts that have it switched on, and on consumer sites many users never do. On most login flows the password step succeeds before the second factor is requested, so the attacker still learns which passwords are valid, and that knowledge is useful for phishing and for push-notification spam aimed at tired users. And every attempt still reaches your servers. A middle way is risk-based MFA: ask for the second factor when a login looks unusual, from a new device, a new country or with a high bot score.

Rate limits that look beyond the IP address

A limit per IP address is the obvious first step, and attackers plan for it: they rotate through proxy pools so that each address stays under your limit. Add limits per account, per device fingerprint and per network range, and watch the overall rate of failed logins. A sudden jump in that rate is often the first sign that a run has started. Slowing down responses after failed attempts costs a real user little and a bot operator a lot of time.

Breached-password checks

Check new passwords at signup and on every password change against a list of passwords known from breaches, and refuse the ones on it. NIST SP 800-63B makes this a requirement for services that follow it: new passwords have to be compared against a blocklist that includes passwords from earlier breaches. Services such as Pwned Passwords from Have I Been Pwned let you run the check without sending the password anywhere. You send the first characters of its hash and compare the returned matches on your own server.

The same check works at login. If someone signs in with a password that appears in a breach, ask them to change it before an attacker gets there.

Bot detection on the login form

Credential stuffing depends on volume. Bot detection on the login form, through a CAPTCHA, a proof-of-work task or device and behavior signals, puts a price on each attempt and marks the ones that look automated. With a bot score your server can treat logins differently: let clean ones through, ask doubtful ones for a second factor and reject the obvious bots.

Validate the result on the server for every login request, and cover every way in: the web form, the API your mobile app uses, older login endpoints, the password reset form and any step that reveals whether an email address has an account. Attackers look for the one entrance without a check.

Can a CAPTCHA stop credential stuffing?

A CAPTCHA helps against credential stuffing, and that is true whichever vendor you pick: hCaptcha, Google reCAPTCHA, Cloudflare Turnstile and TrustCaptcha all make automated login attempts slower and more expensive. None of them stops the attack alone. OWASP points out that CAPTCHAs “are not perfect” and that tools and services exist to break them with a reasonably high success rate, and a login that gets past the CAPTCHA still works if the password is right.

So treat the CAPTCHA as the layer that cuts the volume, and rely on MFA and breached-password checks for the attempts that get through. For login forms, the differences between vendors that matter most are whether your users see a challenge, whether you get a score to act on and where visitor data is processed. The same CAPTCHA on your contact and signup forms also cuts automated spam, and on signup it helps prevent fake account creation by the same kind of automation.

Smaller measures that add up

• Show the same error message for a wrong username and a wrong password, so your login does not tell attackers which email addresses have an account.
• Notify users about logins from a new device. They often spot a takeover before your monitoring does.
• Let users see and end their active sessions.
• Offer passkeys. An account that signs in with a passkey has no password that can leak and be reused.

What to do while an attack is running

1. Raise the friction on the login: increase the proof-of-work difficulty, require the bot check on every login and block the networks the attack comes from.
2. Find the accounts with successful logins from the attack’s IP addresses or devices, end their sessions and force a password reset.
3. Tell the affected users what happened and what they should do, including changing the password on other sites where they used it.
4. Find out whether personal data was accessed, and ask your data protection officer whether the incident has to be reported.
5. Once it is over, check which endpoint the attack used and close that gap.

TrustCaptcha on your login form

TrustCaptcha checks every login in the background. The widget starts on its own and solves a proof-of-work task in the browser, so a real user has nothing to solve or click while a bot pays for each attempt. The proof-of-work gets harder as the risk of a request rises, which makes a run of thousands of logins from suspicious traffic expensive.

From the Solo plan, a bot score and custom proof-of-work rules give your server a signal to act on: let the login through, ask for the second factor or reject it. TrustCaptcha sets no cookies, processes data in EU data centers and includes a Data Processing Agreement for every customer. It is one layer of your login security and works best next to MFA and breached-password checks.

Try TrustCaptcha

Every plan starts with a 14-day free trial, and non-commercial websites can use TrustCaptcha for free. Start your free trial and put a check on your login form that your users never have to solve.