How should teams design password policy for offline attacks?

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.

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?