A login page can be attacked without an adversary knowing anything specific about your password. Instead of hammering one account with thousands of guesses, the attacker can take one password that many people are likely to choose and quietly try it against hundreds or thousands of usernames. That is password spraying.
The pattern matters because it changes both prevention and detection. A service that locks an account after repeated failures may still see only one or two attempts per user. Meanwhile, the attack succeeds wherever a person chose the sprayed password. Credential stuffing looks similar from a distance, but it begins with breached username-and-password pairs and depends on password reuse rather than a broadly popular guess.
Quick answer
Password spraying tests one or a small set of common passwords across many accounts. Credential stuffing tests stolen username-and-password pairs from one service against other services. Spraying asks, “Who chose this predictable password?” Stuffing asks, “Where else did this person reuse a password I already know?”
A unique, randomly generated password protects against both patterns in different ways. It is not among the human-chosen guesses a spraying campaign is likely to try, and it has no value for signing into another service if one provider is breached. A passkey can remove the reusable password secret from a supported sign-in altogether. MFA adds another barrier, preferably through a phishing-resistant method.
A password manager cannot stop requests arriving at a provider's login system. The provider or an organization's identity team must rate-limit attempts, reject common passwords, monitor distributed failures, disable unsafe legacy authentication, and investigate suspicious successful sessions. Your job is to make sure a guessed or previously exposed secret is not enough to take over your account.
Password spraying, credential stuffing, and brute force are not the same attack
| Attack | Input | Attempt pattern | Weakness exploited |
|---|---|---|---|
| Password spraying | One or a few common, expected, or organization-themed passwords | A small number of guesses across many accounts, often slowly or from distributed sources | Predictable password choice and weak provider-side controls |
| Credential stuffing | Username-and-password pairs stolen from another service | Known pairs replayed against other sites, apps, or identity providers | Password reuse |
| Traditional online brute force | A large candidate-password list | Many guesses concentrated on one account or a small target set | A guessable secret plus insufficient throttling |
| Offline password cracking | Stolen password hashes | Guesses evaluated locally without the provider's online rate limit | Weak passwords and weak password-hash protection |
MITRE ATT&CK classifies password spraying as T1110.003: adversaries use one or a small list of common passwords against many accounts. MITRE notes that attackers may deliberately throttle attempts to evade detection and may target cloud applications, single sign-on systems, and externally facing email. Its separate credential-stuffing technique, T1110.004, describes using account credentials obtained from breaches of unrelated services.
Why ordinary account lockout rules may miss a spray
An account lockout is usually scoped to one username: after a threshold of failures, that account is delayed or blocked. A spraying campaign turns that design sideways. The attacker may send only one guess to each username, wait, change the source infrastructure, and later try another common password. No individual account necessarily reaches a simple consecutive-failure threshold.
The attacker first needs possible account identifiers. Those may come from public staff directories, predictable email formats, breach data, sales contacts, or error messages that reveal whether a username exists. The adversary then chooses passwords shaped by common behavior: popular strings, season-and-year patterns, organization names, or superficial variations that satisfy composition rules. If one works, the result is a valid password—not merely a failed-login campaign.
That successful sign-in can be the beginning rather than the end. The attacker may inspect email, create inbox-forwarding rules, register another authentication method, obtain session tokens, change recovery details, or use the account to reach other systems. This is why incident response must examine account activity and persistence, not just change the password.
Microsoft's password-spray investigation playbook tells defenders to correlate identity, federation, firewall, and security logs; establish the timeline and affected accounts; inspect unexpected MFA prompts; and look for mailbox persistence such as forwarding rules or delegations. Those signals exist at the service and organization layer. A local vault does not receive the authentication telemetry required to perform that investigation.
Why “complex enough” can still be predictable
A password can meet an uppercase, lowercase, number, and symbol rule while remaining a common guess. Predictable transformations such as capitalizing the first letter, appending the year, or replacing one letter with a symbol do not make a human-selected base word random. Spraying campaigns are designed around precisely those population-level habits.
NIST SP 800-63B requires verifiers to compare new passwords against a blocklist containing commonly used, expected, or compromised values and to rate-limit failed attempts. NIST's supporting password guidance identifies machine-generated random passwords, blocklists, secure hashing, and rate limiting as more effective modern defenses than piling on composition rules.
These controls are complementary. A provider's blocklist can reject obvious choices at creation time. Rate limiting can restrict online attempts. Risk-based detection can correlate failures across users, networks, geographies, and time. A user-selected unique random password makes it improbable that the account's secret appears in the spray list in the first place.
How to reduce your exposure as an individual
- Replace common or patterned passwords. Prioritize email, financial, cloud-storage, social, carrier, and primary identity accounts.
- Generate a different random password for every remaining password-based account. Do not reuse even a strong password; reuse converts one service breach into credential-stuffing material.
- Use a passkey where the service supports it. A passkey does not give the website a reusable password that can be guessed, stuffed, or phished in the usual way.
- Enable strong MFA. Prefer phishing-resistant passkeys or FIDO2/WebAuthn security keys. If those are unavailable, an authenticator method is generally preferable to SMS. Protect every fallback method.
- Store recovery codes as authentication secrets. Keep them encrypted, do not leave them in screenshots or unprotected notes, and remove obsolete copies after regenerating them.
- Review provider security activity. Investigate unfamiliar successful sign-ins, new devices, changed recovery information, unexpected MFA prompts, inbox rules, connected apps, and sessions.
- Respond to a successful compromise from a trusted device. Change the affected password to a new unique value, revoke sessions and tokens, remove unauthorized recovery or MFA methods, and check connected accounts for lateral impact.
CISA's MFA guidance recommends using the strongest option available and aiming for phishing-resistant MFA. MFA does not make password quality irrelevant: a stolen password may still expose services that do not enforce the second factor, trigger approval fatigue, or become useful through a weak recovery path.
What organizations and service operators should do
End users cannot implement the server-side defenses that identify a low-and-slow spray. Identity providers and organizations need controls that correlate behavior across the whole authentication surface:
- Reject common, expected, context-specific, and known-compromised passwords when they are created or changed.
- Rate-limit failed authentication while avoiding a design that lets attackers trivially lock out every user.
- Detect one-password-to-many-account patterns, distributed sources, unfamiliar infrastructure, impossible travel, and abnormal success following broad failures.
- Require phishing-resistant MFA for administrators, email, remote access, and high-value systems; protect enrollment and recovery with equivalent care.
- Disable legacy authentication paths that bypass modern MFA or conditional-access policy.
- Preserve and correlate identity-provider, federation, endpoint, VPN, firewall, and application logs.
- After confirmed access, revoke active sessions and tokens, examine mailbox rules and delegated access, check newly registered authenticators, and search for lateral movement.
Microsoft documents smart lockout as using separate lockout counters for familiar and unfamiliar locations while also tracking the last three bad-password hashes. CISA's identity and access management best practices likewise distinguish password spraying from other password attacks and recommend layered identity controls, including phishing-resistant MFA.
Krypt's answer: remove predictable and reusable passwords from your side of the equation
Krypt is a local-first zero-knowledge password manager. It can generate and store a different random password for each account, so the password is neither a likely spray guess nor useful on another service. Krypt Pro's password-health tools analyze vault records for weak, reused, and old passwords locally. Its compromised-password checking uses a k-anonymous range-query design rather than uploading the plaintext password.
For supported websites and platforms, Krypt can create, store, list, delete, and use website passkeys. Those are third-party account credentials; they are not the mechanism that unlocks Krypt itself. Krypt can also keep backup codes and private recovery context encrypted so that moving away from a weak sign-in method does not create an exposed recovery trail.
The boundary is important: Krypt cannot observe a provider's authentication logs, recognize a distributed spray, rate-limit an online login endpoint, revoke a compromised session, or guarantee that a provider's recovery process enforces strong authentication. It reduces susceptibility on the user's side. The provider and, for managed accounts, the organization's identity team remain responsible for detecting and blocking the attack.
A practical migration is to start with accounts that control other accounts: primary email, identity providers, mobile carrier, banking, cloud storage, and domain registration. Replace patterned passwords, turn on the strongest supported authentication, encrypt recovery codes, and then use Krypt Pro's password-health view to work through the remainder. For the closely related reuse problem, see Can a Password Manager Find Reused Passwords Without Uploading Your Vault?
Response checklist if you suspect a spray succeeded
- Use a trusted, updated device. If malware or remote access is plausible, isolate and remediate the device before entering replacement credentials.
- Open the provider's official app or type its address directly. Do not follow a security-alert link until independently verifying it.
- Change the affected password to a newly generated unique value. Never create a variation of the old password.
- Revoke active sessions, remembered devices, application passwords, OAuth grants, and tokens where the provider exposes those controls.
- Review recovery email addresses, phone numbers, MFA methods, passkeys, security keys, and backup codes. Remove anything you did not add and regenerate codes if exposure is possible.
- For email accounts, inspect forwarding rules, filters, delegates, sent mail, deleted mail, and recovery messages.
- If the old password was reused anywhere, treat every reuse as exposed and replace each one with a different random password.
- For work or school accounts, notify the security team promptly. Their cross-account logs are necessary to determine whether this was a broader spray.
- Continue monitoring security activity. A password change alone may not terminate sessions or remove persistence established after the attacker signed in.
For signs and containment steps beyond password spraying, use the broader guide How Can I Tell If My Online Account Has Been Compromised?
FAQ
What is the main difference between password spraying and credential stuffing?
Password spraying tests one or a few common passwords across many accounts, while credential stuffing tests username-and-password pairs obtained from another service's breach. Spraying exploits predictable password choices; stuffing exploits password reuse.
Can a unique password stop password spraying?
A long, randomly generated password that is unique to the account makes common-password spraying very unlikely to succeed against that account. It does not stop the provider-side attempts, and it cannot protect a password exposed through phishing, malware, or a service breach.
Does MFA protect against password spraying?
MFA can prevent a correct password from being enough to sign in, but the strength depends on the method and the recovery path. Phishing-resistant passkeys and FIDO2/WebAuthn security keys are stronger than approval prompts or SMS, and all fallback and recovery methods still need protection.
Can Krypt detect a password-spraying attack?
No. Password spraying occurs against the online service, so detection belongs to that provider or an organization's identity and security monitoring systems. Krypt can reduce susceptibility with unique random passwords, Krypt Pro's local password-health analysis, supported website passkeys, and encrypted recovery storage, but it cannot inspect or block provider-side login attempts.
Technical references
MITRE ATT&CK defines Password Spraying (T1110.003) and Credential Stuffing (T1110.004) as separate brute-force sub-techniques. NIST SP 800-63B specifies password blocklisting and authentication rate limiting. CISA publishes identity and access management best practices and guidance to require strong MFA. Microsoft provides a password-spray incident-response playbook and smart-lockout guidance.
Use Krypt to replace predictable and reused passwords with unique random credentials, manage supported website passkeys, keep recovery codes encrypted, and review password risks with Krypt Pro.
