Credential Stuffing Explained covers the attack that tries one already-correct, leaked password against many other sites. Password spraying is its mirror image, and just as common in practice: one guessed — never leaked — password, tried against every account on a single system, one attempt per account, spread out just far enough to slip under the exact defense a normal brute-force attempt would trip.
What password spraying actually is
Password spraying picks a small set of common or predictable passwords — think Winter2026!, Company123!, or whatever is at the top of the latest most-common-passwords list — and tries each one against a large list of usernames, one attempt per account before moving to the next password. The attacker never touches a stolen or leaked credential; they're betting that across enough accounts, some nonzero fraction of real users chose one of a handful of predictable passwords, and they're usually right.
This is the inverse of a classic brute-force attempt, which tries many candidate passwords against one account — spraying tries very few passwords against many accounts. And it's a different mechanism from credential stuffing, which already knows a working password for a specific account because it leaked somewhere else. Spraying doesn't know anything — it's pure guessing, aimed at breadth instead of depth.
Why the "one attempt per account" shape matters
Most account-lockout policies count failed attempts per account: five wrong guesses on one username locks that one username. A classic brute-force attempt runs straight into that threshold on the fourth or fifth try. Password spraying never gets close to it — trying one password against a thousand different usernames means every individual account sees exactly one failed attempt, nowhere near any per-account threshold. The attacker then waits out the lockout-counter reset window (often 15-30 minutes) before trying the next password against the same thousand accounts. Slow by design, and specifically shaped to be invisible to a defense that only watches failures per account.
How the attack actually runs
- Building the username list. Corporate email addresses follow predictable formats (
first.last@company.com), and a company directory, LinkedIn, or a previous breach can supply thousands of real usernames without guessing a single one. - Picking the password set. Seasonal patterns (
Summer2026), the company's own name, and whatever currently tops a most-common-passwords list are the standard choices — not random guesses, but the specific small set of passwords real people actually pick under a policy that requires "one uppercase, one number, one symbol" and nothing more. - Pacing attempts to stay under the lockout threshold. One password per account, then a wait before the next password, timed to the lockout window rather than to how fast the attempt could technically run.
- Targeting federated login where it exists. A single sign-on front door (Microsoft 365, Okta, and similar) is an especially efficient target — one successful guess against the identity provider can grant access to every downstream application behind it, not just one account on one system.
What actually stops it
- MFA. The same logic as credential stuffing applies — a correctly guessed password stops being sufficient the moment a second factor is required. Multi-Factor Authentication Explained covers why this holds regardless of how the attacker obtained a working password, guessed or leaked.
- Banning common passwords at creation, not just checking breach corpora. Breach-checking (covered in NIST Password Guidelines Explained) rejects passwords already known to be compromised — and the specific passwords spraying relies on are frequently in that corpus too, since they're common precisely because so many people have chosen them before. Rejecting them at the moment an account is created removes the exact weak passwords the attack depends on before spraying ever starts.
- Risk-based throttling instead of a flat per-account counter. Rate limiting keyed to source IP, request velocity across many distinct usernames, or impossible-travel signals catches the "one password, many accounts" shape that a purely per-account lockout counter is structurally blind to.
- Monitoring the actual signature. A single source (or a small, related set of sources) authenticating against a large number of distinct usernames in a short window, each with exactly one failed attempt, looks nothing like normal login traffic — and nothing like a classic brute-force attempt either, which is why it needs its own detection rule rather than reusing a per-account failure alert.
None of these fully substitutes for another — banning common passwords closes off the specific values the attack depends on, MFA makes a correct guess insufficient on its own, and behavioral monitoring catches the attempt even when a guess does land.
Common mistakes
- Trusting a per-account lockout policy alone. It's the exact defense password spraying is shaped to evade — one failed attempt per account never reaches the threshold, no matter how many accounts get tried.
- Checking only for leaked passwords, not common ones. A breach-corpus check and a common-password blocklist overlap heavily but aren't identical — a policy should reject both, not treat breach-checking alone as sufficient coverage.
- Setting lockout thresholds low enough to become a denial-of-service vector. An aggressive per-account lockout (one or two failed attempts) can itself be weaponized — an attacker sprays a single wrong password across every known account specifically to lock all of them out, turning a defense into an outage.
- Ignoring SSO amplification. Treating every downstream application as a separate target misses that a single compromised identity-provider account can be the only guess that actually mattered.
FAQ
Is password spraying the same as a brute-force attack?
No. Brute-force tries many passwords against one account. Password spraying tries very few passwords against many accounts, specifically to stay under a per-account lockout threshold that would stop a brute-force attempt quickly.
Does account lockout stop password spraying?
A traditional per-account lockout counter doesn't, by design — the attack never accumulates enough failed attempts on any single account to trigger it. Detection has to look at request patterns across accounts, not failures within one.
Does a long, strong password protect against this?
Only if it isn't also a common one. Length alone doesn't help if the actual value chosen is still on the short list an attacker is spraying — see Minimum Password Length Recommendations for where length does and doesn't carry the weight people assume it does.
Why do federated logins (SSO) matter so much here?
Because one successful guess against the identity provider can be worth dozens of downstream accounts at once, spraying against an SSO front door has a far higher payoff per successful guess than spraying against any single standalone application.
Try it yourself
Password Storage Checker grades whether a system enforces MFA and rate limiting/lockout alongside its hashing and breach-checking practices, and Password Policy Generator and Password Policy Validator check a policy for common-password rejection and rate limiting against NIST SP 800-63B, from either direction. All three run entirely in your browser.