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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “The developer's guide to strong passwords”.
By the numbers:
- 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.
Key questions
Q: How should teams design password policy for offline attacks?
A: Design policy around stolen-hash cracking, not just live login abuse.
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.
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.
Practitioner guidance
- 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.
Bottom line: The core risk is not weak-looking passwords alone, but policy designs that let attackers exploit predictable user behaviour and fast hash cracking.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
07/06/2026 9:42 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Why password policy should focus on length, breach checks, and hashing
This post was modified 4 days ago by NHI Mgmt Group