Hashing and lockouts reduce some attack paths, but they do not prevent an attacker from using a real password that was exposed elsewhere. If the password is reused, guessed, or already present in breach data, the account can still authenticate successfully. The risk persists because trust is being granted to a credential that may already be known to the attacker.
Why compromised passwords can still authenticate successfully
A hashed password is safer at rest, but hashing does not change whether the underlying password value is still accepted at login. If the same password has been reused, exposed in another breach, or guessed offline, an attacker can simply present the real secret and pass the check. The weakness is in credential trust, not storage format.
That is why password compromise remains an authentication problem even when a system never stores plaintext. The account may still be vulnerable wherever the same password is valid, especially across services that do not share breach intelligence or block known-compromised values.
Why lockout policies reduce abuse but do not eliminate risk
Lockouts mainly slow online guessing and credential stuffing. They do not stop an attacker who already has a valid password and can log in on the first attempt, nor do they stop password spraying at low volume across many accounts. They also create a separate operational trade-off: too-aggressive lockouts can increase help desk load and be abused for denial of service.
Password Security and Password Manager Guide explains why modern password policy has moved away from brittle complexity rules and toward controls that reduce reuse, block known-breached passwords, and encourage unique secrets per service.
What actually changes the risk profile
The strongest reduction comes from preventing reuse, rejecting breached passwords, and using phishing-resistant authentication where possible. Hashing remains important for storage protection, but it is not a compensating control for a password that an attacker can already obtain or predict. Once a password is known, the account is only as strong as the login path in front of it.
RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants shows the broader pattern of moving away from shared secrets toward stronger client authentication, while RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) demonstrates how sender-constrained credentials reduce replay value after theft.
Risk and Threat Considerations
Compromised passwords remain risky because attackers can use them directly in credential stuffing, password spraying, or account takeover attempts. Lockout policies only raise the cost of repeated guessing, they do not neutralise a password that is already valid in the target service or on a reused account elsewhere.
Failure mechanism: The defender protects storage and rate limits, but the attacker bypasses both by presenting a real, accepted password that was reused, leaked, or predicted from breach data.
Impact: A single compromised password can still enable authenticated access, privilege escalation, data exposure, or persistence wherever that credential is trusted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password compromise and reuse are authenticator lifecycle issues. |
| IA-2 — Identification and Authentication (Organizational Users) | The question is about whether a password still authenticates a user after exposure. | |
| AC-7 — Unsuccessful Logon Attempts | Lockout policies directly map to limiting repeated failed logins. | |
| Recommendation — Block breached passwords and rotate exposed credentials quickly. Require stronger authentication where password-only trust is too weak. Tune failed-logon thresholds to slow abuse without creating easy lockout attacks. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account abuse from reused or compromised passwords is an account-control problem. |
| Recommendation — Harden account controls and disable risky shared credentials. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Guidance on phishing-resistant and high-assurance authentication informs password-risk reduction. |
| Recommendation — Adopt phishing-resistant authentication for sensitive access paths. | ||
Practitioner Guidance
What to prioritise: Treat any exposed or reused password as a login-risk event, not just a storage issue. If the password appears in breach data or is used on multiple systems, rotate it and look for other accounts that may share the same secret.
What to verify: Confirm whether the control blocks known-compromised passwords at creation and reset, whether lockout thresholds are tuned to stop abuse without creating easy denial-of-service conditions, and whether high-value accounts use stronger authentication than password-only access.
Practitioner takeaway: Hashing protects the database, but it does not protect trust in the credential itself; the real control objective is to keep known or reused passwords from being accepted in the first place.