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 modern password policies should prioritise length, breach checks, and slow hashing over outdated complexity rules.

Why it matters: It matters because the same governance mistake shows up across human IAM, NHI secrets, and autonomous systems: controls built for convenience and compliance often fail against real attacker behaviour.

By the numbers:

• A modern rig with 8× RTX 4090 GPUs can test ~164 billion MD5 hashes per second.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read WorkOS's developer guide to stronger password policy and hashing

Context

Password policy is the set of rules that controls how users create, store, and recover credentials, and this article argues that many common rules still reflect an outdated threat model. For human IAM, the problem is not whether a password looks complex on the surface, but whether it can survive offline cracking after a breach and whether the surrounding controls reduce reuse, stuffing, and replay.

The same logic extends beyond passwords. When organisations over-focus on symbolic complexity, they often miss the real governance question: how to make credentials resilient after exposure, and how to limit the damage when a secret, token, or password inevitably leaks. That is relevant to human authentication, NHI secrets, and any identity programme that depends on stored credentials.

Key questions

Q: How should security teams build password policy that resists real attacks?

A: Security teams should prioritise password length, breach-list screening, and slow hashing over composition rules and forced rotation. The goal is to make stolen credentials expensive to crack and useless to reuse. Pair that with MFA and session revocation so a compromised password does not become a durable account takeover path.

Q: Why do complexity rules often make passwords less secure?

A: Complexity rules push users toward predictable patterns such as Password1!, seasonal changes, and leet-speak substitutions. Attackers already encode those patterns in cracking rules, so the policy creates false confidence without adding much entropy. Longer passphrases usually provide better security and are easier for users to remember.

Q: What breaks when organisations force periodic password rotation?

A: Periodic rotation often produces small, predictable mutations of the previous password, which attackers can guess quickly once they know one historic value. It also adds friction for users and support teams without addressing the real problem, which is exposure. Rotation should follow compromise signals, not the calendar.

Q: Should organisations use breach monitoring before changing password policy?

A: Yes, because breach monitoring tells you when a credential is actually exposed instead of assuming risk on a fixed schedule. That lets teams rotate only the accounts that need it and focus on reuse, stuffing, and session invalidation. It is a more accurate control than routine calendar changes.

Technical breakdown

Offline cracking is the real password threat

Modern attackers rarely guess passwords against a live login form for long. They prefer offline cracking, where a copied hash database is attacked locally at machine speed with GPUs and wordlist rules. That changes the defender's job: rate limits, CAPTCHAs, and lockouts only help online, while hash strength, salting, and algorithm choice determine what happens after a breach. Slow, memory-hard hashing such as Argon2id raises the cost of each guess and makes large-scale cracking materially harder.

Practical implication: choose password hashing settings for post-breach resistance, not just login friction.

Length beats complexity for password entropy

Entropy measures how much search space an attacker must cover. Each extra character multiplies the search space, which is why long passphrases usually outperform short, mixed-character strings that look complex but follow predictable human patterns. Requirements for uppercase letters, digits, and symbols often produce Password1! style habits that cracking tools already target with rule engines. A longer passphrase with no forced substitutions is usually easier for users and harder for attackers.

Practical implication: raise minimum length, then remove character-class rules that encourage predictable substitutions.

Breach-list checks and salt harden authentication after exposure

Checking new passwords against breached credential lists blocks reused passwords at the point of creation, which is where many credential-stuffing attacks begin. Salting then makes identical passwords produce different hashes, defeating rainbow tables and preventing one cracked value from scaling across accounts. Together, these controls shift password policy from appearance-based compliance to exposure-aware governance. That is the practical distinction between a policy that looks strict and one that actually narrows attacker leverage.

Practical implication: reject compromised passwords and store every password with a unique, automatic salt.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Password policy is still too often designed for user compliance, not adversary economics. The article shows that online brute force is the easy problem and offline cracking after hash theft is the hard one. That shift matters because many organisations still reward visible complexity while underweighting hash resistance, breach-list screening, and credential reuse controls. The practitioner conclusion is blunt: the control objective is to make stolen credentials expensive to exploit, not merely hard to type.

Length-based policy is a better governance primitive than composition rules. Complexity requirements create predictable user behaviour, which in turn creates predictable attacker rules. That is a human-factor failure, not just a user-experience issue. NIST SP 800-63B aligns with this reality by favouring length and breach checks over forced uppercase, digit, and symbol patterns. The practitioner conclusion is to treat password policy as entropy management, not character counting.

Credential exposure and password governance are part of the same NHI problem space. The same pattern that makes password rotation weak also shows up in service-account secrets and API keys: once a secret is exposed, calendar-based remediation rarely matches attacker speed. That is why the NHI lifecycle conversation cannot stay separate from human authentication design. The practitioner conclusion is to align password policy, secret rotation, and breach response around exposure events, not arbitrary time cycles.

Offline attack economics create a governance blind spot that boards rarely see. A policy can look strict on paper and still collapse under GPU-scale guessing if the stored hash format is too fast or the user population reuses passwords. The article’s math makes that gap concrete. The practitioner conclusion is to report password controls in terms of breach resilience, not just policy conformance.

Strong password rules are necessary but not sufficient, because authentication is now a system problem. The article correctly pairs length, breach monitoring, session management, and MFA, which is the right way to think about credential risk. Passwords fail most often when they are treated as an isolated control instead of one layer in a broader identity stack. The practitioner conclusion is to measure end-to-end account takeover resistance, not isolated password complexity scores.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the same report.
• That gap is why the Guide to the Secret Sprawl Challenge is the right next step for teams dealing with exposed credentials and recovery lag.

What this signals

Password policy is not an authentication-only problem. The same governance gap that lets users choose weak passwords also appears in service-account secrets and API keys, where exposure often persists long enough to be exploited. Teams that are modernising identity controls should treat password rules, secret storage, and breach response as one control family rather than separate workstreams.

Length, breach checking, and slow hashing should be the baseline, not the end state. NIST CSF 2.0 and NIST SP 800-63B both support a shift away from compliance theatre and toward risk reduction. For teams managing human identity and NHI credentials in the same environment, the practical signal is simple: controls must reduce the value of a stolen credential after exposure, not merely make enrollment more annoying.

For practitioners

• Raise minimum length and remove composition rules Set a minimum length of at least 12 characters and stop requiring uppercase, digit, and symbol combinations that drive predictable user substitutions. Enforce a higher maximum length as well so passphrases are not silently constrained.
• Block breached and domain-specific passwords at creation time Check every new or changed password against a breached-password corpus and a local blocklist that includes company names, product names, and common keyboard walks. Reject matches before account creation or reset completes.
• Use slow, memory-hard password hashing Store passwords with Argon2id where possible, or bcrypt with an appropriately tuned cost factor, and verify that salts are generated automatically. Do not use fast general-purpose hashes for credential storage.
• Trigger rotation only on evidence of compromise Replace calendar-based password rotation with event-driven remediation when credentials appear in breach data, are reused externally, or are linked to suspicious session activity. Treat rotation as a response control, not a routine hygiene cycle.
• Pair passwords with MFA and session revocation Require MFA for account access and invalidate active sessions when risk indicators appear, so a stolen password does not remain useful for the full lifetime of the session. This is especially important where support teams still handle password resets manually.

Key takeaways

• Most weak-password failures are governance failures, not user failures, because policy still rewards visible complexity over real crack resistance.
• The scale problem is now attacker economics: GPU-assisted offline cracking turns stolen hashes into a fast-moving risk even when live login controls are strict.
• Teams should move to longer passwords, breached-password rejection, slow hashing, MFA, and event-driven rotation to reduce account takeover exposure.

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.
• 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.
• Breached-Password Screening: Breached-password screening is the practice of rejecting passwords that appear in known compromise datasets. It stops reused or already exposed credentials at the moment of creation or reset, which is often the most effective place to interrupt credential-stuffing and account takeover attempts.
• Memory-Hard Hashing: Memory-hard hashing is a password storage approach that requires substantial memory as well as computation to verify each guess. That makes large-scale GPU cracking less efficient than with fast one-way hashes, because attackers cannot parallelise brute force as cheaply across many cores.

Deepen your knowledge

Password policy, breach-list screening, and secure hashing are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning human authentication with broader identity governance, it is worth exploring.

This post draws on content published by WorkOS: The developer's guide to strong passwords. Read the original.