Why would I spray one password instead of brute-forcing one account?

Because lockouts are keyed per account. Brute-forcing one user with many passwords trips that account's lockout after a few tries and you are done. Spraying sends one password to many accounts, so each account sees a single attempt and never locks, while you still cover the whole user base. On any target with a sane lockout policy, spraying is the attack that actually keeps working, and it only needs one user who picked the password you are spraying.

What is the difference between credential stuffing and brute force?

Brute force generates password guesses; credential stuffing replays real username and password pairs leaked from other breaches. Stuffing works because people reuse passwords, so a combo that worked on one site often works on another. It is high-yield and low-effort when you have a breach corpus, and it does not look like guessing because each pair is a real password, just for the wrong site. Defenses are breach-password checks and anomaly detection, not lockout alone.

Authentication Vulnerabilities: The Complete Practical Guide

Password-Based Attacks: Brute Force, Spraying, and Stuffing

How brute force, password spraying, credential stuffing, and default credentials work, when to use each, and why spraying beats brute force on real targets.

Published October 25, 2026

Once you know which accounts exist, you go after the passwords. There are four distinct plays here, and picking the right one for the defenses in front of you is the whole skill. Spray when there is lockout, stuff when you have breach data, brute-force when there is neither, and always try default credentials first. This page covers each and when it wins. Practice on a free live target.

The four plays

Vertical brute force: one username, many passwords. Simple, but trips per-account lockout almost immediately.
Password spraying: one common password, many usernames. Stays under per-account lockout because each account sees only one attempt.
Credential stuffing: replay real username and password pairs from other breaches, betting on reuse.
Default credentials: the vendor or setup password nobody changed.

Each targets a different weakness: brute force attacks a weak password, spraying attacks a common password across a weak population, stuffing attacks reuse, and defaults attack neglect.

Try default credentials first

Before anything clever, try the credentials that ship with software or get set during install and never changed:

admin:admin        admin:password     admin:admin123     admin:changeme
root:root          root:toor          administrator:administrator
guest:guest        test:test          user:user          demo:demo
admin:<blank>      tomcat:tomcat      postgres:postgres  sa:<blank>

Admin panels, databases, appliances, and dev tools are the usual offenders. It costs a handful of requests and sometimes ends the engagement immediately.

Password spraying: the real-world winner

On any target with a lockout policy, spraying is the attack that keeps working. You take a single plausible password and try it against every username you enumerated, so no single account accumulates enough failures to lock. Then you wait out the window and spray the next password. Effective spray passwords follow human patterns:

Welcome1   Password1   Password123   <Company>2024!   Summer2024!
Spring2025!   Changeme123   Qwerty123!   P@ssw0rd   <Season><Year>!

Tailor them to the target: the company name with a year and a bang, the current season, the local sports team. You only need one user in the whole directory who picked the password you are spraying, and in a large enough population there usually is one.

Credential stuffing: betting on reuse

If you have a breach corpus of real email:password pairs, replay them. People reuse passwords across sites, so a pair that worked somewhere else often works here. Stuffing does not look like guessing, because every password is a real one, just borrowed from another site. It is high-yield when you have the data and is defended by breach-password checks and anomaly detection rather than lockout.

Build a targeted wordlist

A smart small list beats a giant generic one, because every wasted attempt brings you closer to a lockout or a detection threshold. Pull from:

Vendor and software defaults for the stack you fingerprinted.
Seasonal and keyboard patterns (Summer2024!, Qwerty123!).
The company name, product names, and local references from OSINT.
Any password-policy hints the app leaks (minimum length, required symbol), to prune guesses that cannot be valid.

Watch for the success tell

A successful login looks different from a failed one, and that difference is your signal: a 302 redirect to a dashboard, a Set-Cookie session header, a different response length, or simply the absence of the error string. When you automate, key your success condition on that tell rather than on the absence of an error, which can be fooled by rate-limit pages.

Note that landing a valid password is not always the end. If the account has MFA, you have the first factor only and need MFA and OTP bypass to finish.

Fixing it

Check passwords against known-breach corpora at signup and reset so reused and common passwords are rejected outright.
Rate-limit and monitor for spray and stuffing patterns (many accounts with one password, or many attempts from one source).
Prefer exponential backoff over hard per-account lockouts, which attackers weaponize into denial of service.
Require MFA, so a correct password alone is not enough.

Full defensive detail is in securing authentication. Next, see how the throttles that are supposed to stop all this get bypassed in flawed brute-force protection, or try a spray on a free lab.

← Back to Authentication Vulnerabilities: The Complete Practical Guide