Notifications
Clear all
Topic starter
07/06/2026 7:57 pm
TL;DR: Modern password cracking uses GPU-powered offline attacks against stolen hash databases, making length, breach-list checks, and slow hashing more important than complexity rules, according to WorkOS and NIST SP 800-63B. The old model assumes users will create random passwords and rotate them safely, but attackers exploit predictable substitutions and forced changes.
NHIMG editorial — based on content published by WorkOS: The developer's guide to strong passwords
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- The full password hashing comparison, including when bcrypt, scrypt, and Argon2id differ in practical deployment.
- The code-level example for breach-list checks using k-anonymity and local validation flows.
- The detailed rate-limiting and lockout patterns for online brute-force defence.
- The passphrase generator approach and strength-meter implementation guidance for developers.
👉 Read WorkOS's developer guide to stronger password policy and hashing →
Password policy is probably wrong: what should teams change now?
Explore further
07/06/2026 9:42 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Why password policy should focus on length, breach checks, and hashing
