Credential stuffing is an automated attack in which someone takes username and password pairs leaked from one website and tries them against the login page of another, betting that people reuse the same password in both places. It differs from brute force because the attacker is not guessing: each pair is a real credential that worked somewhere, so a meaningful share of attempts can succeed even though every individual request looks like an ordinary login. You stop it by making a stolen password insufficient on its own (phishing-resistant MFA and passkeys), by rejecting passwords already known to be breached, and by slowing and filtering automated traffic before it reaches your login.
The rest of this post covers how the attack works, how it differs from brute force and password spraying, what the signals look like in your logs, and which defenses matter most, with the configuration for each on Keycloak 26.x, the open-source server behind our identity management as a service. It is aimed at engineers responsible for a login page, and the final section is a checklist for schools and member platforms, which attackers target because they hold many long-lived accounts that users rarely update.
What is a credential stuffing attack?
OWASP’s Credential Stuffing Prevention Cheat Sheet treats it as the automated replay of breached username and password pairs to gain access to user accounts, and it is catalogued in OWASP’s list of automated threats to web applications as OAT-008. The attacker needs three things: a list of leaked credentials (traded in bulk, often compiled from many breaches), a tool that replays them, and a pool of IP addresses so that no single address looks busy.
The tool sends each pair to your login endpoint and records which ones return a success. Working accounts are then used directly, sold, or mined for data. Because the credentials are real, the attacker can run a low-volume campaign across many accounts and still collect a steady number of valid logins.
How is credential stuffing different from brute force and password spraying?
All three are automated password attacks, and they are often confused because they all show up as failed logins.
| Credential stuffing | Brute force | Password spraying | |
|---|---|---|---|
| What is tried | Leaked username and password pairs | Many guesses against one account | One or a few common passwords against many accounts |
| Source of guesses | Previous breaches | Dictionaries and generated candidates | Lists of common passwords |
| Why it works | Password reuse across sites | A weak password on the target account | Some users choose very common passwords |
| Typical pattern | One or two attempts per account, many accounts | Many attempts per account | Few attempts per account, many accounts |
| Stopped by per-account lockout | Rarely, since each account is tried only once or twice | Yes | Rarely |
The last row is the reason credential stuffing is awkward for defenders. Account lockout, the standard answer to brute force, is designed around many failures on one account, and a stuffing run produces almost none. Keycloak’s built-in brute force detection works per account in just this way, which is a gap we describe in the blind spot of IP limits and lockout DoS.
What signals show credential stuffing in your logs?
Because individual requests look normal, detection is about patterns across requests:
- A high ratio of failed to successful logins over a short window, especially when the failures are for accounts that exist and the passwords are simply wrong.
- Many different accounts attempted from one IP address, one network or one autonomous system, or the inverse: a flood of distinct IP addresses each trying one account.
- Logins from locations or devices the account has never used, particularly a success immediately after a failure.
- Unusual client fingerprints: the same user agent string at high volume, missing browser headers, or requests that skip the pages a real browser would load first.
- Impossible travel, where one account logs in from two distant places within minutes.
- A sudden rise in password reset requests or account lockouts, which can mean the attacker is probing for valid usernames.
In Keycloak, turn on event logging for login and login-error events so these patterns exist to be queried.
Which defenses work best, in order of impact?
1. Make a stolen password insufficient
The single most effective control is removing the password as the only gate. Phishing-resistant multi-factor authentication and passkeys mean that a leaked password pair fails even when it is correct. Keycloak supports WebAuthn and passkeys, and our passkeys and WebAuthn guide covers enabling them as a first factor or as a second factor, while why passwordless matters gives the wider case. Where you cannot require MFA for everyone, require it for administrators and for any account that can see other people’s data.
Be aware that SMS and email codes raise the cost of an attack without stopping a determined one, and that push-based MFA has its own abuse pattern, covered in MFA fatigue and helpdesk vishing.
2. Reject passwords that are already breached
Rejecting breached and common passwords when a user sets one reduces how many accounts a leaked list can open, although it does not affect passwords users already have. NIST SP 800-63B-4, the current digital identity guideline on authentication, requires verifiers to check chosen passwords against a blocklist of commonly used, expected or compromised values, prohibits composition rules such as mandatory symbols, and favors length.
Keycloak provides a Password Blacklist policy that compares a new password with entries in a blocklist file stored on the server. The policy does not query a breach database on its own, so the quality of the check depends on the list you load, and on a managed service you would ask your provider to load it. Our password policy guide shows how to set it up alongside minimum length and the other policies.
3. Rate-limit and filter automated traffic before the login page
Attackers rely on volume, so controls at the edge are the most direct way to raise their cost. This means rate limits per IP and per network, and blocking known bad sources. Keycloak itself is not built to be this layer, which is why Skycloak offers a WAF and rate limiting as add-ons that sit in front of the realm, described in securing Keycloak with Skycloak’s configurable WAF.
One caution applies to any IP-based block: attackers rotate addresses cheaply, and shared networks such as a campus or an office can put many legitimate users behind one address. Treat IP limits as a way to slow and shape traffic, not as the main defense.
4. Turn on brute force detection, knowing its limits
Brute force detection is off by default in Keycloak and has to be enabled under Realm settings, Security defenses, Brute force detection. According to the Server Administration Guide it applies to password, OTP and recovery code authentication, and it can lock accounts temporarily or permanently after repeated failures. It is worth enabling because it stops straightforward guessing and slows some stuffing runs, but it counts failures per account and does little against a low-and-slow campaign across thousands of accounts. A permanent lockout setting also hands attackers a way to lock out real users on purpose, so temporary lockout is usually the safer choice.
5. Add step-up and short sessions where the stakes are high
Require a fresh MFA check before sensitive actions such as changing an email address or exporting data, and keep session lifetimes short for administrator roles, so that one successful login does not become long-lived access. The same logic applies to stolen sessions, which we cover in session hijacking in the infostealer era.
6. Collect less data in the identity system
If a login succeeds despite everything above, the damage is limited by what that account can reach. Keep the identity provider’s user profile minimal and avoid storing data there that applications do not need to read at login. The Keycloak security audit checklist covers other hardening steps for the realm.
What should schools and member platforms do first?
Education and membership organizations hold a large number of accounts that people rarely update, which makes them natural targets. A practical order of work:
- Turn on event logging and look at a week of login failures to learn what normal looks like.
- Enable brute force detection with temporary lockouts.
- Load a password blocklist and set a minimum length. NIST SP 800-63B-4 sets 15 characters for passwords used on their own and 8 when the password is one factor of MFA.
- Require MFA for staff and administrators first, then offer passkeys to everyone else.
- Put rate limiting and bot filtering in front of the login page.
- Tell users to use a unique password for their institution account, since reuse is what the attack depends on.
The Skycloak page for education describes how this looks for schools, and the advanced security and multi-factor authentication feature pages list the controls available.
Frequently asked questions
What is the difference between credential stuffing and brute force?
Brute force guesses passwords for an account, usually with many attempts, while credential stuffing replays real username and password pairs leaked elsewhere. Stuffing makes few attempts per account, so account lockout is a weak defense against it.
Why does credential stuffing work?
It works because many people reuse one password across several sites. When one site is breached, those pairs become valid keys to every other site where the same email and password were used.
How can I tell if my site is under a credential stuffing attack?
Look for a surge in failed logins across many different accounts, many accounts tried from the same address or network, successful logins from unfamiliar places, and a rise in password resets. These patterns appear only if login events are logged and reviewed.
Does MFA stop credential stuffing?
It stops the attack from turning a correct password into a login, as long as the second factor is not itself guessable or phishable. Passkeys and other phishing-resistant factors are the strongest option.
Is credential stuffing the same as a data breach?
No. A data breach is the original theft of data from a system. Credential stuffing is a later attack that reuses data from earlier breaches to get into other, unrelated systems.
Can a CAPTCHA prevent credential stuffing?
It can slow it down, but attackers use solving services and real browsers, so a CAPTCHA works best as one layer alongside rate limiting, breached-password checks and MFA.