Design policy around stolen-hash cracking, not just live login abuse. That means longer minimums, breach-list screening, and a slow password hashing algorithm that makes each guess expensive. Complexity rules and forced rotation do not materially improve resistance if the attacker already has the database.
What offline password attacks actually target
Offline attack resistance is about what happens after an attacker already has password verifier data, such as a database dump, backup, or synced replica. At that point the question is no longer whether login throttling works, because the attacker can try guesses without interacting with your live authentication service. The policy has to make each guess slow, costly, and detectable by other means.
That is why policy should be tuned to the cracking problem, not just to live sign-in abuse. The most effective levers are password length, checking against known-compromised passwords, and strong hashing with an adaptive work factor. If a password can be brute-forced from stolen hashes, the online login controls were never the main defence.
Why length, breached-password screening, and slow hashing matter
Longer passwords raise the search space and make offline guessing materially harder, especially when the attacker is limited to generic cracking rigs rather than a user-facing rate limit. Breached-password screening removes choices that are already common in attack dictionaries, which is important because many real-world compromises start with reused or previously exposed secrets.
A slow password hashing algorithm changes the economics of attack. The point is not to make passwords mathematically unbreakable, but to increase the cost per guess enough that weak, reused, and medium-strength passwords become uneconomical to crack at scale. For teams comparing implementation options, the password guidance in Password Security and Password Manager Guide is the most directly relevant internal reference for length, blocklists, reuse, and hashing choices.
Complexity rules are a poor substitute for these controls because attackers do not guess by following composition policy, they guess by using real-word patterns, breaches, substitutions, and password spraying dictionaries. Forced periodic rotation is also weak against offline compromise if the attacker already has the hash, because changing the password after a leak does not make the stolen hash any harder to crack.
How to balance policy with real attack conditions
Offline resistance improves most when the policy assumes the database may be lost. That means the strongest practical policy is usually one that permits long passphrases, blocks known-compromised values, and uses a modern memory-hard or otherwise expensive hashing configuration with well-tuned parameters. The control objective is to make the stolen verifier data much less useful, not to make every user follow a rigid composition recipe.
Hashing and password policy should be treated as complementary, not interchangeable. Policy helps by raising the quality of chosen secrets, while hashing protects the stored form of those secrets if the application layer fails. When teams get this wrong, they often overinvest in complexity checks and underinvest in storage protection, which leaves them exposed to the exact scenario offline attackers prefer.
Risk and Threat Considerations
Offline attacks create a different failure mode from normal account login abuse: once hashes are stolen, the attacker can work quietly, at scale, and without triggering lockout or anomaly controls on the live system. The main risk is that weak or reused passwords are eventually recovered, which can then be reused for account takeover, privilege escalation, or lateral movement.
Failure mechanism: Password hashes are captured from a system breach, backup exposure, or insider access, and the attacker uses large-scale guessing against weak passwords, common wordlists, and previously breached credentials until one cracks.
Impact: Accounts can be compromised long after the original incident, and weak policy choices can turn a single data exposure into broad credential reuse risk across other systems.
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, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers password lifecycle, verifier protection, and rotation decisions for offline attack resistance. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies because password policy governs how organizational users authenticate and what quality of secret is accepted. | |
| SC-28 — Protection of Information at Rest | Password hashes and related verifier data require at-rest protection because offline attacks begin after data exposure. | |
| Recommendation — Enforce strong authenticator lifecycle controls and use current, expensive password storage settings. Set authentication requirements that favour long secrets and reject weak passwords. Protect stored authentication data so stolen verifier material is harder to exploit. | ||
| OWASP ASVS | V6 — Authentication | Password strength, breached-password checks, and verifier handling are core authentication verification topics. |
| V11 — Cryptography | Password hashing cost and storage strength are directly tied to cryptographic protection of verifiers. | |
| Recommendation — Verify password policy accepts long secrets and blocks compromised choices. Use a modern password hashing scheme with parameters set to resist offline guessing. | ||
| CIS Controls v8 | CIS-5 — Account Management | Password policy is part of account protection and credential governance for user access. |
| Recommendation — Tighten account credential rules so stolen hashes are less useful to attackers. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Password handling and verifier protection are governed by authentication-information controls. |
| Recommendation — Apply authentication-information controls that reduce the value of exposed password data. | ||
Practitioner Guidance
What to prioritise: Treat password policy as a stolen-hash problem first. The first priority is to prevent easy cracking of weak or reused passwords, then to ensure the stored verifier is expensive to attack if exposure occurs.
What to verify: Confirm that the minimum length is generous enough to support passphrases, that breached-password screening is enforced, and that the hashing configuration is current and intentionally slow rather than legacy-default.
Common mistake: Do not equate complexity with strength. A password that satisfies symbol rules can still be easy to guess offline if it is common, reused, or short enough to crack cheaply.
Practitioner takeaway: The best offline password policy is one that assumes the hash store may be stolen and still makes the attacker pay heavily for every guess.
Related resources from NHI Mgmt Group
- How should security teams build password policy that resists real attacks?
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- How should security teams reduce the risk of password guessing attacks in Active Directory?