Why password policy should focus on length, breach checks, and hashing

At a glance

What this is: This is a developer-focused analysis of why password policy should move away from complexity rules and forced rotation toward length, breached-password screening, and slow hashing.

Why it matters: IAM and application security teams need this because password rules that look strict can still fail against offline cracking, reuse, and predictable user behaviour.

By the numbers:

• A modern rig with 8× RTX 4090 GPUs can test about 164 billion MD5 hashes per second.
• bcrypt at cost factor 12 still drops to about 6,800 hashes per second per GPU.
• Knowing a user's previous password allowed researchers to guess the next one in fewer than 5 attempts for 17% of accounts.

Context

Password policy is the set of rules that govern how users create and manage passwords, and the central problem here is that many legacy rules optimise for visible complexity instead of real resistance to cracking. For application teams, that gap matters because the attacker model has shifted from live guessing to offline attacks against stolen hash databases.

WorkOS frames the issue as a mismatch between policy and attack economics. If a policy makes passwords easier to predict, reuse, or mutate while leaving hashing fast enough for GPUs, it increases exposure even when it appears strict on paper.

The article is aimed at developers and authentication teams, and its starting position is typical of the broader industry: many organisations still carry forward password rules that were designed before modern cracking tools and breach datasets became routine.

Key questions

Q: How should teams design password policy for offline attacks?

A: 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.

Q: Why does password complexity alone often fail as a security control?

A: Password complexity alone fails because it improves theory more than real-world resilience. Users who must log in repeatedly are pushed toward workarounds, slower productivity, and weaker adherence. When controls interrupt core workflows, business users resist them. Stronger authentication plus automation is more effective because it reduces dependence on remembered secrets and lowers the chance of exposure through manual entry.

Q: What are the signs that a password policy is failing in practice?

A: Common warning signs include frequent help desk resets, users making only tiny changes to old passwords, repeated complaints about rejected passwords, and visible workarounds such as password reuse or note-taking. If employees routinely bypass controls to save time, the policy is creating friction without improving protection and should be redesigned around usability and actual risk.

Q: Should organisations prioritise breach checks or password rotation?

A: Prioritise breach checks first. Screening against known compromised passwords stops reused secrets at the point of creation, while calendar rotation often produces predictable mutations that add friction without reducing exposure. Rotation should be triggered by compromise evidence, not by a schedule.

Technical breakdown

Why offline hash cracking changes password policy

Modern password attacks are often offline, meaning attackers steal a hash database and then test guesses locally at GPU speed. That changes the security objective from stopping repeated login attempts to making each hash expensive to verify. Rate limits, lockouts, and CAPTCHAs help against online brute force, but they do almost nothing once the database is copied. The practical distinction is critical: live authentication controls protect the door, while hashing and password choice determine how quickly a thief can open the safe after breach.

Practical implication: prioritise controls that reduce the value of stolen hashes, not just controls that slow live login attempts.

Why length beats complexity rules

Password strength is driven by entropy, which grows much faster with additional characters than with small changes in character classes. A long passphrase expands the search space far more than a short password padded with a symbol or digit. Complexity rules also create predictable patterns because users respond with the same substitutions, suffixes, and capitalisation habits. That makes the policy look strict while leaving the underlying guessability largely intact. From a governance perspective, the point is not aesthetics or user preference. It is whether the policy actually changes attacker cost.

Practical implication: set longer minimums and remove composition requirements that only encourage predictable transformations.

How breached-password checks and slow hashing work together

Breach-list screening stops known bad passwords at the point of creation, which is especially important in a world of credential stuffing and password reuse. Slow hashing then reduces the rate at which an attacker can test any stolen credential offline. The two controls address different failure modes: one blocks reused secrets before they enter the system, the other makes any stolen hash harder to exploit at scale. Salting is part of that model because it prevents identical passwords from producing identical hashes and defeats precomputed lookup tables.

Practical implication: combine breached-password screening with Argon2id, bcrypt, or scrypt and treat salting as non-optional.

Threat narrative

Attacker objective: The attacker wants usable credentials that survive beyond a single site and can be reused for account takeover elsewhere.

1. Entry occurs when attackers obtain a password hash database through SQL injection, a breach, an insider, or misconfigured storage.
2. Credential access then shifts offline, where GPU-powered cracking tests billions of guesses per second without touching the live authentication system.
3. Impact follows when reused or weak passwords are recovered and used to compromise other accounts or services.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Length is the control that changes the economics of offline cracking: Complexity rules are easy to satisfy and easy to predict, which means they often shift behaviour without materially increasing attacker cost. A password policy only works when it forces the search space to grow faster than user memorisation habits can collapse it. For IAM teams, that makes minimum length the primary design variable, not a cosmetic requirement.

Breached-password screening is the real first-line control for credential reuse: Reuse is not a side issue here, it is the bridge between one breach and many. Checking new passwords against known breach datasets directly interrupts that bridge, while complexity rules leave it intact. The governance lesson is that password policy should treat known-compromised strings as a control failure, not a user preference issue.

Slow hashing turns stolen data into a constrained asset rather than a reusable one: Fast hashes were built for integrity checks, not password storage, and that design assumption breaks under modern GPU economics. Argon2id, bcrypt, and scrypt create deliberate computational friction that scales poorly for attackers. The practitioner implication is that password governance now sits inside cryptographic operations as much as inside identity policy.

Predictable rotation proves why calendar-based password change is a broken premise: Rotation policy was designed for credentials that change less often than human habits do. That assumption fails when users mutate the same secret into a new pattern that remains guessable. The implication is that password lifecycle should be event-driven and compromise-aware, not timer-driven.

Password policy is now a developer security control, not just an IAM setting: Application teams decide whether length caps, breach checks, and hash selection are enforced at creation time or left to downstream guidance. That makes secure defaults part of the identity boundary. Practitioners should treat password creation logic as application control surface, not a front-end convenience layer.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• According to Forrester Research, a single password reset can cost around $70.
• Read next: Password Security and Password Manager Guide

What this signals

Breach-list screening is the decisive policy shift: Password rules that still rely on complexity and periodic rotation miss the point that attackers now work from stolen hashes and reused credential sets. A policy that rejects known-compromised passwords changes the economics of account takeover before the first login ever happens.

Password policy should be treated as an application control, not a documentation exercise: The password creation flow is where users either inherit secure defaults or inherit the organisation's weakest assumptions. That is why length, hash choice, and breach checks belong in the authentication path, not in a static policy page.

The State of Secrets in AppSec shows that only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap. Password policy fails for the same reason when the implementation burden is pushed onto users instead of enforced in the product.

For practitioners

• Adopt longer minimum password lengths Set a minimum of 12 characters or more, and support at least 64 characters so passphrases can be used without truncation or silent failure.
• Remove complexity and rotation rules Eliminate uppercase, digit, and symbol requirements, and stop forcing periodic changes unless there is evidence of compromise.
• Screen against breached-password lists Reject passwords that appear in known breach datasets at registration and reset time, and use local or k-anonymity checks where appropriate.
• Use slow password hashing Store passwords with Argon2id, or bcrypt and scrypt where needed, and configure them so offline guessing is materially expensive.
• Expose realistic strength feedback Show estimated crack time or passphrase guidance so users understand risk in terms that reflect attacker effort rather than checkbox compliance.

Key takeaways

• The core risk is not weak-looking passwords alone, but policy designs that let attackers exploit predictable user behaviour and fast hash cracking.
• The article grounds that argument in modern cracking economics, including GPU-speed offline attacks and research showing predictable rotation outcomes for a meaningful share of accounts.
• The most effective response is to raise password length, block breached passwords, and store credentials with slow hashing that materially raises attacker cost.

Key terms

• Offline Password Cracking: Offline password cracking is the process of attacking a copied hash database without touching the live authentication system. It matters because the attacker can use GPU-scale guessing and rule engines at machine speed, so hash choice, salting, and password length become the real controls.
• Breach Data Screening: Breach data screening is the practice of checking passwords or other secrets against known compromised credential repositories before they can be used. It helps identify unsafe credentials in real time and forces remediation before attackers can exploit them. This is a control layer, not a one-time cleanup activity.
• Slow Password Hashing: Slow password hashing uses deliberately expensive computation to store passwords in a way that makes guessing more costly. Schemes such as bcrypt, PBKDF2, and scrypt are built for this purpose. They do not make passwords uncrackable, but they raise the attacker’s cost enough to improve resistance against offline guessing.
• Password Entropy: Password entropy is a measure of how hard a password is to guess by brute force. In practice, longer passwords increase entropy more reliably than short strings that rely on symbols or case changes, especially when attacker tooling already knows the common human patterns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.