NIST to forbid requirement of specific passwords character composition

Original Article ↗ Hacker News Discussion ↗

NIST’s updated digital identity guidelines now explicitly prohibit common password rules such as mandatory character mixes and arbitrary rotation, and discourage security questions, instead favoring longer passphrases and better technical controls. Commenters welcome the shift as aligning with real-world usability and modern tools like password managers, but note that many enterprises, regulators, and legacy systems still enforce outdated policies due to compliance checklists and inertia. The exchange highlights how overly complex or inconsistent password requirements can reduce security in practice by encouraging unsafe workarounds and poor implementation choices such as silent truncation.

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.