Password spraying is an attack in which someone tries one or a few very common passwords (such as a season and a year, or the company name) against a large number of accounts, instead of trying many passwords against one account. Because each account sees only one or two failed attempts, the per-account lockout that stops ordinary brute force never triggers, and the attacker simply collects whichever accounts happen to use a weak password. The defenses that work are the ones that do not depend on counting failures per account: multi-factor authentication or passkeys, rejecting weak and breached passwords when people set them, and rate limits and monitoring keyed on the source of the traffic.
This post explains how spraying works, how it differs from credential stuffing and brute force, what it looks like in your logs, and how to defend a login page against it, including the settings that matter on Keycloak 26.x, the open-source server behind our identity management as a service. It is written for engineers who own a login for a B2B SaaS product or a member platform.
What is a password spraying attack?
The MITRE ATT&CK framework catalogues the technique as Brute Force: Password Spraying (T1110.003) and describes it as trying a small set of commonly used passwords against many accounts, which avoids the account lockouts that a single-account attack would cause. The attacker starts with a list of usernames, which is often easy to build because most organizations use predictable email formats, and picks a password that some users in any large population will have chosen. Then the attacker goes down the list, trying that one password on each account, and waits a while before trying the next password so that no account sees many failures in a short window.
The result is a handful of valid logins out of thousands of attempts. That is enough, because one working account at a company is often enough to reach email, files or an internal application, and from there the attacker can move further. At that point the incident looks like account takeover, whatever technique started it.
How is password spraying different from credential stuffing and brute force?
All three produce failed logins, and all three are automated, which is why they get confused. The difference is what the attacker already knows.
| Password spraying | Credential stuffing | Brute force | |
|---|---|---|---|
| What is tried | One or a few common passwords | Username and password pairs leaked from other sites | Many passwords against one account |
| Accounts targeted | Many | Many | One at a time |
| Where guesses come from | Lists of common passwords | Previous breaches | Dictionaries and generated candidates |
| Why it works | Some users pick very common passwords | Users reuse passwords across sites | The target password is weak |
| Failures per account | One or two | One or two | Many |
| Tripped by per-account lockout | Rarely | Rarely | Yes |
| Best signal in logs | Many usernames failing from one source | Many distinct accounts with a few failures each, often from many addresses | Many failures on one account |
| Best control | MFA plus a password blocklist | MFA plus breached-password checks | Lockout plus MFA |
In short, spraying guesses a few common passwords across many accounts, stuffing replays real leaked pairs, and brute force tries many passwords on one account. Our post on what credential stuffing is covers the replay case in detail. Spraying is cheaper for the attacker to start, since it needs no breach data, and it is weaker per attempt, since it relies on the guess being common.
Why does per-account lockout fail against it?
Account lockout counts failures on each account and locks the account at a threshold. NIST’s SP 800-63B, the US digital identity guideline, asks verifiers to limit consecutive failed attempts on a single account (the earlier 2017 edition gave 100 as a ceiling, so check the current text for the figure). A spraying run sits far under any sensible threshold, because it makes one or two attempts per account, so the counter never reaches it.
Lockout also has a cost. Anyone who can guess usernames can deliberately fail logins to lock real users out, which is a denial of service. Keycloak’s built-in brute force detection is disabled by default and, when you turn it on, works per account, which we cover in our post on Keycloak’s brute-force blind spot. The Keycloak administration guide itself suggests pairing the feature with intrusion prevention software that watches the log of failed logins and client IP addresses, which is the kind of control spraying calls for.
What does password spraying look like in your logs?
Because the pattern is spread across accounts, you find it by looking across accounts:
- Many distinct usernames failing from the same IP address, network or autonomous system, each with only one or two failures.
- Failures arriving in slow, evenly spaced waves, where the attacker deliberately waits between rounds.
- Failures against accounts in alphabetical or list order, which looks like a script walking a directory.
- A success after several failures elsewhere from the same source, which suggests a guess landed.
In Keycloak, turn on login and login-error events and keep them long enough to query; each failure carries the client IP address and the username attempted. Our guide to Keycloak event logging and auditing lists the event types.
How do you stop password spraying?
In rough order of impact:
- Make a correct password insufficient. Require multi-factor authentication, and prefer passkeys or other phishing-resistant methods where you can, so a guessed password does not open a session. This is the one control that stops a guessed password from producing a session. See our pages on multi-factor authentication and passwordless login.
- Stop weak passwords at creation. NIST SP 800-63B expects new passwords to be checked against lists of commonly used and previously breached values. Keycloak has a password policy called Password Blacklist that compares a new password with a plain-text list file kept on the server, so you can load a list of common passwords and refuse them (on a managed service you would ask your provider to load the file).
- Rate limit by source, not only by account. Put limits on login and token requests per IP address (and per network) at your reverse proxy or web application firewall, since Keycloak does not do this itself. Distributed sprays use many addresses, so this slows an attack without stopping it. Our post on Skycloak’s configurable WAF describes one way to apply it.
- Tune lockout so it does not become the problem. Prefer temporary lockout with short waits over permanent lockout, so attackers cannot lock out real users for long. Our production readiness checklist has a baseline.
- Alert on the cross-account pattern. A rule such as “more than N distinct usernames failing from one source in M minutes” catches what per-account counters miss.
- Do not leak which usernames exist. Return the same message for a wrong username and a wrong password, as discussed in our post on error handling that balances user experience and security, so attackers cannot cheaply build a list of valid accounts.
A short checklist for B2B SaaS and member platforms
Platforms with long-lived accounts that people rarely visit (member portals, alumni systems, partner logins) are good targets, because a weak password can sit untouched for years. Check that every admin and staff account requires a second factor, that the weakest cohort of accounts has been forced through a password reset since you added a blocklist, that your proxy limits login attempts per source, and that someone gets alerted when failures spread across many accounts.
Frequently asked questions
What is the difference between password spraying and brute force?
Brute force tries many passwords against one account and is stopped by lockout. Password spraying tries one or a few passwords against many accounts, so each account sees too few failures to lock.
Is password spraying the same as credential stuffing?
No. Credential stuffing replays real username and password pairs from earlier breaches, relying on reuse. Spraying guesses common passwords and needs no breach data.
Can multi-factor authentication stop password spraying?
It stops it from producing a working session, because a correct password is not enough. The attacker still learns which accounts have weak passwords, so also reset those, and prefer methods that resist phishing.
Does Keycloak protect against password spraying by default?
Brute force detection is disabled by default, and when enabled it counts failures per account, so it does not catch a spray. Use MFA, a password blacklist policy, and IP-level controls in front of Keycloak.
How can I tell a spray from ordinary mistyped passwords?
Ordinary mistakes cluster on a few accounts and come from the users’ usual locations. A spray touches many accounts with one or two failures each, from a small set of sources, often in regular waves.