Skip to content
tooljo Password tools
100% in your browser. Nothing you paste is uploaded — all processing runs locally. Read more →

Why password complexity rules (mostly) make passwords worse

5 min read #password #policy #security

In 2003, NIST Special Publication 800-63 told the world: passwords need at least one uppercase letter, one number, one symbol, and should be changed every 90 days. Twenty years later, those rules are still on half the corporate intranets you’ll ever log into.

The author of the original rules, Bill Burr, publicly apologised in 2017. NIST published a complete replacement (SP 800-63B) the same year. The new advice: stop forcing complexity; stop forcing rotation; check against breach lists; let users have long passwords or passphrases.

Half a decade on, most policies still demand the broken old rules. Here is why each one backfires, with the math.

Rule 1: “Must contain uppercase, lowercase, digit, symbol”

What this looks like in practice: a user picks a memorable word, capitalises the first letter, appends a digit, and adds !. Sunshine1!. Or Tigers2024!. Or Password123!.

These passwords look “complex.” They aren’t.

hashcat: ?u?l?l?l?l?l?l?l?l?d?s

That’s the actual mask hashcat (a popular cracker) uses for “8 chars with capital first, then 7 lowercase, then a digit, then a symbol.” The keyspace is roughly 2^41 — defeated in hours on commodity GPUs.

The “complex” password defeated a 12-character all-lowercase random password (about 56 bits) by orders of magnitude.

The complexity rules constrain the password to live inside a tiny predictable subset of all possible passwords, then cracking tools walk that subset first.

The fix in NIST SP 800-63B: don’t enforce complexity. Let users pick whatever they want. Verify against a breach list and minimum length. Done.

Rule 2: “Change your password every 90 days”

The intended threat model: an attacker stole your hash before, brute- forced it for two months, and your shifted-by-90-days password has already moved on by the time they crack it.

The actual outcome: users append a sequential digit or month name. Sunshine1! becomes Sunshine2! becomes Sunshine3!. Or January2024! becomes April2024!.

Cracking tools test this pattern in the first 100 attempts.

Worse: forced rotation encourages weak patterns, because the user has to remember several variants. So the base password becomes simpler — easier to mutate, easier to crack.

Worse still: people write the rotated passwords down because remembering the rotation schedule is hard. Now there’s a sticky note under the keyboard.

NIST 2017: don’t force rotation. Force change only on suspicion of compromise (breach, account anomaly). Keep good passwords indefinitely.

Rule 3: Maximum length limits (“8–14 characters”)

Some legacy systems reject passwords over 14 or 16 characters. This defeats both passphrases and high-entropy random passwords. Users have no choice but to live in the short, structured-pattern space the crack tools own.

Why does it exist? Two reasons, both bad:

  1. The system stores plain-text passwords in a database column with a fixed VARCHAR(14) size.
  2. The system uses a hashing algorithm that pre-processes inputs to a fixed size (e.g., truncates input to 14 bytes, like LM hash).

Both are red flags about server-side security. If a site rejects your 20-character password, assume bad hashing on the back end and use a unique long-but-truncatable password (16 chars) plus 2FA.

NIST 2017: allow at least 64 characters. Allow Unicode. Don’t truncate.

Rule 4: Security questions (“What’s your mother’s maiden name?”)

Security questions are passwords with three terrible properties:

  1. Lower entropy than the password. “Mother’s maiden name” is from a list of ~5,000 surnames. ~12 bits.
  2. Often public. LinkedIn, ancestry sites, wedding announcements.
  3. Reused across sites. Your high-school’s name is the same answer on every site that asks it.

NIST: use real second factors. SMS is weak; TOTP (authenticator app) is good; FIDO2 / passkey is best. Security questions are a fallback designed for a 2003 threat model that no longer applies.

Rule 5: “Don’t write it down”

Writing down a 6-word passphrase on paper, locked in your home, is genuinely safer than memorising a 6-character one. The threat model matters: physical paper inside your house is harder to steal at scale than a phished password is to harvest.

NIST 2017: don’t ban writing passwords down. Ban online storage without encryption. A locally-stored password manager is the right artefact; an unencrypted Notes file synced to the cloud is not.

What modern password policy should actually be

Per NIST SP 800-63B (current as of this writing):

  1. Minimum length: 8 characters. (Some go higher; 12 is a fine choice.)
  2. Maximum length: at least 64. Don’t truncate.
  3. Allow all printable characters including Unicode. No char-class restrictions.
  4. No forced rotation. Change on compromise only.
  5. No security questions as a primary recovery method. Use proper 2FA.
  6. Verify against breach lists (haveibeenpwned API).
  7. Server-side: argon2id or bcrypt for storage (see hash.tooljo.com/which-hash-function).
  8. Rate-limit failed attempts. Online brute force should be infeasible.
  9. Allow paste, password managers, and long inputs in all fields.

Why hasn’t this caught on?

Three reasons:

  1. Compliance frameworks lag. SOC 2, PCI DSS, and others reference the old rules. Passing audit with the new rules requires explanation; passing with the old rules is automatic.
  2. Existing password databases were created under old rules. The stored passwords are short and structured. A migration to better policy is a project most teams defer.
  3. Habit + consultant inertia. Security checklists from 2010 still circulate. The 90-day rotation rule still ships in templates.

If you’re building a new system, please follow NIST 2017+. If you’re on the user side: use a password manager, generate long random strings or passphrases, ignore the rules where you can, and don’t ever reuse.

Try the tools