For decades, the standard password advice was "8 characters, one uppercase, one number, one symbol." NIST quietly walked that back in 2017, and the rest of the industry caught up by 2024. The new rule is simpler and stronger: length beats complexity. This guide explains why, with the actual math.
The old rule was wrong
The "complexity" rule — requiring mixed character classes — was based on a reasonable idea (more character classes means more possibilities per position) but produced terrible real-world outcomes:
- Users picked "Password1!" because it satisfies every rule and is trivially crackable.
- Forced symbol changes led to "Password1!", "Password2!", "Password3!" — predictable patterns.
- Short complex passwords are weaker than long simple ones, but the rules never punished length.
The math of password entropy
Password strength is measured in bits of entropy. Each bit doubles the search space. The formula is simple:
entropy = length × log2(charset_size)Some worked examples:
- 8 chars, lowercase only (26 charset): 8 × 4.7 = 37.6 bits — cracked in seconds on a GPU.
- 8 chars, full ASCII (94 charset): 8 × 6.55 = 52.4 bits — cracked in hours.
- 16 chars, lowercase only: 16 × 4.7 = 75.2 bits — centuries on commodity hardware.
- 16 chars, full ASCII: 16 × 6.55 = 104.8 bits — longer than the age of the universe on current hardware.
Doubling the length of a password adds more entropy than adding a symbol class. 16 lowercase letters (75 bits) beat 8 chars with every symbol (52 bits) by 23 bits — a factor of 8 million in crack time.
What NIST actually says now
NIST Special Publication 800-63B (current revision) dropped the complexity requirement entirely. The key recommendations:
- Minimum 8 characters. (Many security teams push 12 or 16 internally.)
- Maximum length must be at least 64 characters — no artificial caps.
- Accept all printable ASCII and Unicode (including spaces — passphrases are encouraged).
- Check new passwords against a breached-password list (haveibeenpwned API or similar).
- No mandatory periodic rotation — forced rotation leads to weak predictable patterns.
- No knowledge-based authentication (mother’s maiden name, first pet, etc.).
- Allow paste — password managers should be encouraged, not blocked.
Passphrases: the better pattern
A passphrase is 4–6 random words strung together. Example: "correct-horse-battery-staple" (the famous XKCD pattern). At 25 lowercase characters, that is 117 bits of entropy — stronger than any 12-character complex password, and dramatically easier to type and remember.
For human-typed passwords, use passphrases. For machine-stored credentials (password managers, API keys), use 20+ character random strings.
Why randomness matters
Length alone is not enough if the characters are predictable. "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" is 30 characters but zero entropy — it is in every cracking dictionary. Real randomness means using a CSPRNG (cryptographically secure pseudo-random number generator), not Math.random and not your brain.
Our Password Generator uses the Web Crypto API (window.crypto.getRandomValues), which is the same CSPRNG your browser uses for TLS. The output is safe for production credentials.
Hashing: the last line of defense
Even strong passwords must be hashed before storage. Plain SHA-256 is not enough — it is too fast, so an attacker with the hash can brute-force billions of guesses per second. Use a memory-hard, slow hash function:
- Argon2id — current best practice, winner of the Password Hashing Competition.
- bcrypt — battle-tested, still recommended, configurable work factor.
- scrypt — memory-hard, good alternative.
- PBKDF2 — acceptable but weakest of the modern options; use 600,000+ iterations.
For non-password use cases (file checksums, data integrity), plain SHA-256 is fine. Use a Hash Generator to produce SHA-256, SHA-1, SHA-512, or MD5 hashes for any text input.
The breached-password problem
A 16-character random password hashed with bcrypt is essentially uncrackable. But if that same password appeared in a breach, an attacker just looks it up. Always:
- 1Use unique passwords per service (a password manager makes this trivial).
- 2Check your passwords against Have I Been Pwned before adopting them.
- 3Rotate immediately if a service you use announces a breach.
Two-factor authentication
No password, however strong, is a complete defense. Enable 2FA everywhere it is offered. Prefer:
- Hardware keys (YubiKey, Titan) — phishing-resistant, strongest option.
- TOTP apps (1Password, Authy, Aegis) — strong, free, widely supported.
- SMS — only when nothing else is offered. Vulnerable to SIM-swap attacks.
Practical recommendations
For 2026, here is what we recommend for different use cases:
- Personal accounts: 20+ character random passwords in a password manager, unique per site.
- Shared team credentials: 24+ character random passwords, stored in a team password manager with audit logs.
- API keys and service tokens: 32+ character random strings, rotated quarterly, scoped to minimum permissions.
- Master password for your password manager: a 4–6 word passphrase you can actually remember.
The bottom line
Password security in 2026 is simpler than the old "complexity" rules made it seem. Length is the dominant variable. Randomness is non-negotiable. Hashing is mandatory. Use a CSPRNG-based generator, aim for 20+ characters, and let a password manager handle the storage. Generate your next password with our Password Generator — it uses the Web Crypto API, runs entirely in your browser, and never transmits a byte.