Why most password policies are counterproductive
Most corporate password policies were written in the early 2000s and mandated quarterly rotation, mandatory complexity (upper + lower + number + symbol), and length minimums of just 8 characters. Research has since shown that these rules reliably produce worse passwords: users rotate “Password1!” to “Password2!” and satisfy every complexity rule while remaining trivially crackable.
The US National Institute of Standards and Technology (NIST) revised its Digital Identity Guidelines (SP 800-63B) in 2017 and again in 2024, producing recommendations that are directly at odds with most legacy policies. Understanding the new guidance is essential for any team serious about account security.
This guide is aimed at developers, IT administrators, and business owners setting password policies for their teams or applications. For testing individual password strength interactively, use the Password Strength Checker.
NIST SP 800-63B: the key principles
1. Minimum length of 8 characters (but aim higher)
NIST sets 8 as the absolute minimum for user-chosen passwords. In practice, 12–16 characters is the recommended floor for 2025, and 64 characters should be the maximum. Longer passwords are almost always better, and passphrases of four or five common words (“correct horse battery staple”) are much harder to crack than short complex passwords.
Policy rule: Minimum 12 characters. No arbitrary maximum below 64.
2. No mandatory rotation without cause
NIST explicitly states: “Verifiers should not require that memorised secrets be changed arbitrarily (e.g., periodically).” The reason: forced periodic changes produce predictable patterns. Users increment a number, change a season, or append a character — all of which cracking tools expect.
Change passwords when:
- There is evidence of compromise (from a breach notification or anomaly detection)
- The user requests it
- A privileged account has had administrative access revoked
Policy rule: No mandatory periodic rotation. Require change on suspected or confirmed compromise.
3. Check against known-breached passwords
NIST requires that any new or changed password be checked against lists of known compromised passwords. The Have I Been Pwned (HIBP) Pwned Passwords dataset contains over 800 million password hashes from real breaches, available via a k-anonymity API that reveals nothing about the full password.
Policy rule: Reject any password that appears in the HIBP Pwned Passwords dataset. Implement this check server-side at registration and password-change time.
4. Do not impose composition rules
Mandatory uppercase + lowercase + number + symbol requirements do not improve security. Instead:
- They produce predictable patterns (“Word1!” satisfies every rule)
- They reduce the effective password space by constraining where each character type can appear
- They prevent users from choosing strong passphrases that happen to not include symbols
NIST explicitly recommends against composition rules. Enforce length. Enforce breach screening. Let the user choose how to meet those constraints.
Policy rule: No composition rules. Length + breach screening is the right combination.
5. Allow all Unicode characters
NIST says verifiers should accept all printable ASCII characters and should accept Unicode characters. Many policies incorrectly block spaces (which enable passphrases), em-dashes, or non-Latin characters.
Policy rule: Accept all printable ASCII (including space) plus Unicode. Strip only unprintable control characters.
6. Provide strength feedback
When a user is setting a password, the interface should show them a real-time strength indicator rather than a list of arbitrary rules. The Password Strength Checker demonstrates this pattern — it shows crack time and character class breakdown rather than a checklist. Integrate a strength meter in your registration and password-change flows.
Policy rule: Show real-time strength feedback. Guide toward longer passwords rather than enforcing specific character classes.
Two-factor authentication: the most important policy decision
No password policy is complete without a 2FA mandate. Even a well-chosen, unique password provides no protection if it is phished. 2FA adds a second factor that an attacker cannot obtain from a breach dump.
Policy choices:
- TOTP (time-based one-time password): Apps like Google Authenticator, Authy, or 1Password generate 6-digit codes that rotate every 30 seconds. Resistant to replay attacks. Best for most teams.
- Hardware security keys (FIDO2/WebAuthn): Physical tokens like YubiKey. Most phishing-resistant option. Recommended for privileged accounts.
- SMS OTP: Better than nothing, but vulnerable to SIM-swapping. Avoid for high-value accounts.
- Email OTP: Same caveat as SMS — if the email account is compromised, OTP is compromised too.
Policy rule: Require 2FA for all administrative accounts and for all accounts with access to sensitive data. Offer it optionally to all users and encourage uptake.
Account lockout and rate-limiting
Brute-force attacks (trying thousands of passwords against one account) are mitigated by:
- Lockout after N failed attempts: NIST recommends locking after 100 consecutive failures (not 3–5, which causes excessive friction and can be weaponised for denial-of-service). Use exponential back-off before locking entirely.
- Rate limiting: Implement per-IP and per-account rate limits.
- CAPTCHA after N failures: Present a CAPTCHA before allowing further attempts.
Do not lock accounts after 3 or 5 failures — that threshold is low enough to be exploited as a denial-of-service vector against targeted users.
Privileged accounts deserve a higher bar
For service accounts, admin accounts, root access, or API keys:
- Minimum 20-character random passwords (machine-generated, stored in a secrets manager)
- Rotate on every use for one-time credentials
- Hardware 2FA mandatory
- Just-in-time access: Elevate privileges only when needed, revoke immediately after
- Audit every login: Alert on off-hours or off-location logins
Communicating the policy to your team
A policy that no one understands is worse than no policy — it leads to workarounds. Pair your policy document with:
- A password manager recommendation (Bitwarden is free and open-source; 1Password and Dashlane are excellent paid options)
- A demo of the Password Strength Checker so team members understand how strength is evaluated
- A clear explanation of why mandatory rotation is gone (because it creates worse passwords, not better ones)
- A step-by-step guide to enabling 2FA for your primary services (Google Workspace, GitHub, Slack, etc.)
Summary
A modern password policy covers four pillars: minimum length (12+ characters), no arbitrary rotation, breach database screening, and 2FA for all privileged access. Complexity rules, short rotation windows, and arbitrary lockouts after 3 failures are legacy patterns that reduce security rather than improving it. Build the policy from the NIST guidelines, automate the breach-screening check at the API level, and pair it with a password manager rollout.