Password Security: Current Guidance Without Crack-Time Hype

Password security should not be driven by changing crack-time charts or speculative AI claims. Real risk depends on password reuse, online controls, verifier storage, phishing, endpoint compromise, recovery, and whether stronger phishing-resistant authentication is available.

Publication boundary: This article provides general educational and operational guidance. Publishing it does not mean ITECS or any specialist approved a reader’s organization-specific implementation, measured its results, made a legal or compliance determination, or verified a vendor’s configured capability.

Separate online and offline attacks

Online guessing is constrained by the service’s rate limiting, detection, and account protections. Offline guessing depends on whether an attacker obtained password-verifier data and on the storage scheme and cost. A universal time-to-crack table cannot represent these different conditions.

Set usable password controls

• Permit long passwords and passphrases and support broad character entry.
• Screen new passwords against a blocklist of common or compromised values.
• Do not force arbitrary periodic changes without evidence of compromise or user request.
• Allow password managers, autofill, and paste so users can maintain distinct passwords.
• Store verifier passwords with salt and a suitable password-hashing scheme.

Use stronger authenticators where risk warrants

Passwords remain vulnerable to phishing and reuse. Evaluate phishing-resistant cryptographic authenticators for important workforce, administrator, remote, finance, and sensitive-data access. Match authentication assurance, device trust, enrollment, accessibility, lifecycle, and emergency access to the service risk.

Protect recovery and the password manager

Treat account recovery, help-desk verification, authenticator binding, synced credentials, password-manager vaults, master secrets, devices, exports, and emergency access as security paths. Test loss, theft, compromise, offboarding, and recovery without weakening the primary control.

Next step for your environment

Review one important service against current NIST password, MFA, storage, rate-limit, recovery, and password-manager requirements, then close evidence gaps.

Record the accountable owner, baseline, source date, decision, exceptions, acceptance evidence, and review trigger. Test consequential changes in a bounded environment, maintain a rollback path, and verify the real result before closing the work. Product names, availability, pricing, legal requirements, and security guidance can change; recheck the primary sources whenever the decision is renewed or the environment changes.

Before approval, separate observed facts from assumptions, assign every unresolved gap, and preserve the evidence needed to reproduce the decision. Revisit the outcome after implementation so incomplete activity is not mistaken for durable improvement.

If you need an independent baseline before changing production systems, start with an ITECS technology and security assessment and keep the resulting evidence with the decision record.

Sources and update trigger

• NIST — SP 800-63B-4 Authentication and Authenticator Management
• NIST — SP 800-63B-4 HTML publication
• CISA — Cybersecurity Performance Goals

Review trigger: Review after service, threat, authentication technology, NIST guidance, compromise, recovery process, provider, or workforce changes.