NIST to forbid requirement of specific passwords character composition

Original Article ↗ Hacker News Discussion ↗

Overall reaction to updated NIST guidance

  • Many are pleased that composition rules (“must contain upper/lower/digit/symbol”) and arbitrary rotation are now a strict “SHALL NOT”.
  • Several note NIST has recommended against these since at least 2017; the change mainly upgrades “SHOULD NOT” to “SHALL NOT”.
  • Some criticize NIST for years of earlier guidance that shaped today’s legacy systems, but others argue those older rules were state‑of‑the‑art at the time.

Adoption, policy, and compliance inertia

  • Strong skepticism that large organizations, banks, and enterprises will change quickly.
  • Corporate security, auditors, and “cyber insurance” requirements are seen as major blockers; they often enforce outdated checkbox policies.
  • Some report modern employers already avoid periodic password changes and lean heavily on SSO and MFA; others still face frequent forced rotation.

Security questions and recovery mechanisms

  • New guidance deprecating security questions is widely welcomed.
  • Many treat security question answers as passwords stored in a manager, often with random or false-but-plausible answers.
  • Concerns:
    • Answers sometimes stored in plaintext and visible to support agents.
    • Customer support staff can be socially engineered into accepting “I typed random junk” as correct.
    • Field length limits and validation (e.g., “must be a name”, 25-char truncation) reduce entropy and reliability.

Password length, truncation, and hashing

  • NIST’s minimum 64-character maximum is praised; low limits (e.g., 8–20 chars) and bans on spaces are heavily criticized.
  • People report sites that:
    • Truncate passwords silently on signup or login.
    • Reject “too random” passwords.
    • Have inconsistent limits between forms.
  • Discussion of bcrypt, DES-based hashes, LM/NTLM, and DoS risks around extremely long passwords; consensus that:
    • You need an upper length limit to avoid DoS.
    • Silent truncation is never acceptable; passwords should be rejected instead.

Usability, password managers, and real-world behavior

  • Many advocate password managers, long random passwords, and passphrases (e.g., diceware).
  • Others admit using simple, reused passwords for low-value sites due to TV/console/mobile UX and login friction.
  • There’s frustration with constant MFA prompts and complex flows; some see this as evidence of a need for a new authentication paradigm (e.g., passkeys, PAKE), though specifics are left unclear.