Strong Password Rules — NIST vs IT Policy

Corporate policy still demands: one uppercase, one lowercase, one digit, one symbol, change every 30 days, no repeats of the last 24 passwords. Users respond with Welcome2026! → Welcome2026!! and a sticky note under the keyboard. That is not stubbornness — it is rational adaptation to a bad ruleset. NIST-style guidance has pushed the industry toward length, screening, and breach response instead of complexity theater.

What modern guidance emphasizes

• Longer is better — Allow long passwords (well past 12; many systems allow 64+).
• Check against breached and common lists — Block password, season+year, company name+123.
• Allow all printable characters — Including spaces for passphrases; do not forbid paste.
• Hash with a modern KDF — Argon2id, bcrypt, or scrypt on the server.
• Rotate on evidence — Compromise, phishing, shared password detection — not monthly ritual.

Mandatory composition rules often reduce entropy in practice by steering everyone into the same predictable shapes. Attackers know those shapes; users invent them under deadline.

IT policy versus user behavior

Rule	Intended effect	Common real effect
Complexity classes	Harder guesses	NameSeasonYear! patterns
30-day expiry	Limit exposure window	Predictable increments; reuse variants
No paste	Stop malware?	Stops managers; increases reuse
SMS reset only	Convenience	SIM-swap risk; prefer app TOTP or passkeys

If policy fights password managers, policy loses — quietly, in spreadsheets of reused credentials.

Building a policy people can follow

1. Minimum length high enough (for example 12–15+) with a higher recommendation for admins.
2. Maximum length generous; truncate nothing silently.
3. Blocklist commonly breached passwords.
4. Permit paste and managers.
5. Offer passkeys / WebAuthn where possible as the preferred path.
6. MFA for sensitive systems — passwords alone are not enough for admin planes.
7. Rotate when leaked; educate instead of shaming.

Generate high-entropy secrets locally with password-generator when provisioning service accounts or personal vault entries — then store them in a manager, never in Slack.

Passphrases and random passwords

Both work if the generator is sound:

• Random 20+ character strings from a large alphabet (manager-generated)
• Diceware-style passphrases of several unrelated words

Human-invented “clever” passwords are the weak set. Cleverness is not entropy. Service accounts and CI secrets deserve the same generator discipline: long random strings in a vault, rotated when people leave the team or a leak is suspected, never embedded in screenshots of “temporary” .env files.

Implementation notes for developers

• Never invent your own hashing.
• Constant-time compare for verification.
• Rate-limit login and reset endpoints.
• Do not log passwords or put them in analytics events.
• Support paste events on password fields.
• Prefer passkey enrollment UX that is easier than the password form.
• Reject truncated storage — if you silently cut at 16 characters, you trained users to type longer secrets for nothing.

Migrating a legacy complexity policy

Change the written standard, update the IdP rules, and tell employees why: “We are blocking known-bad passwords and encouraging managers instead of forcing monthly punctuation rituals.” Expect fewer reset tickets over a quarter — that is a success metric.

Measure what matters after the change: reused-password detections (if you have a checker), MFA enrollment percentage, help-desk reset volume, and phishing-resistant factor adoption. If resets spike briefly while people learn managers, that is transitional noise — not a reason to bring back Must include $@!.

Strong policy matches how humans and attackers actually behave. Favor length, screening, managers, MFA/passkeys, and evidence-based rotation — and retire the sticky-note industrial complex.