Password entropy isn't what you think

The most common piece of password advice is also the most counterproductive: "make it complex." A "complex" password — one that satisfies the usual must-have-uppercase-lowercase-digit-symbol-and-be-at-least-8-chars rule — is often weaker than a long, simple one. The math is unambiguous.

Here's the actual story.

What entropy measures

Password entropy is the binary logarithm of the number of possible passwords that could have been generated by the same process. A password chosen uniformly at random from 100 possibilities has log₂(100) ≈ 6.64 bits of entropy. A password chosen from a trillion possibilities has log₂(1,000,000,000,000) ≈ 39.86 bits.

The threshold for "uncrackable by any plausible adversary" is about 80 bits in 2026. State actors with custom ASICs can theoretically test 10¹² guesses per second; 2⁸⁰ ≈ 10²⁴ guesses, which is about 30,000 years at that rate. Below 80 bits, you're betting on attacker resources; above 80 bits, you're betting on physics.

Length beats charset, by a lot

Compute per-character entropy:

• Lowercase only (26 chars): log₂(26) ≈ 4.70 bits per character
• Lowercase + digits (36): log₂(36) ≈ 5.17
• Lowercase + uppercase + digits (62): log₂(62) ≈ 5.95
• Full keyboard (95): log₂(95) ≈ 6.57

So:

• 8-character all-symbol password: 8 × 6.57 = 52.6 bits (weak)
• 16-character lowercase password: 16 × 4.70 = 75.2 bits (close to safe)
• 20-character lowercase: 20 × 4.70 = 94 bits (safe)
• 12-character full-charset: 12 × 6.57 = 78.9 bits (close to safe)
• 16-character full-charset: 16 × 6.57 = 105 bits (very safe)

A 20-character lowercase password is stronger than a 12-character one with every symbol on your keyboard. Length doubles entropy per character class, but multiplies through length linearly. The "complexity rule" is almost beside the point.

Why complexity rules backfire

The xkcd 936 password "Tr0ub4dor&3" has about 28 bits of entropy because:

• Real-world users mostly pick one base word
• Substitute predictable characters (o → 0, a → 4)
• Add a digit and symbol at the end

Attackers know this. They build dictionaries of common words, run substitution rules, append the obvious digits/symbols. The "complex" password collapses into the dictionary attack's search space.

The same xkcd's better alternative ("correct horse battery staple") has ~44 bits of entropy from four random dictionary words. Six random words (diceware-style) is ~77 bits — comparable to a 16-character random lowercase password.

NIST's 2024 update to SP 800-63B explicitly drops the composition rules. Section 5.1.1.2: "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types) for memorized secrets." Allow length, encourage length, and stop forcing patterns that backfire.

Where most users actually lose

In practice the biggest password risk isn't entropy. It's reuse.

If you use the same 16-character password across 50 sites and one of them gets breached, every account is compromised. Attackers run credential stuffing — taking a breach dump and trying every (email, password) pair against major services. Reused passwords cause more account takeovers than weak passwords do.

The fix is mechanical: every account gets a different random password, and a password manager remembers them. You only need to remember the manager's master password (which should itself be 24+ characters and not reused anywhere).

The single best password-security upgrade most people can make in 2026 is "stop reusing passwords." Two-factor authentication is next. Password strength is third — important, but a 16-character random password isn't getting cracked; the leak path is reuse, not entropy.

Generating real entropy

If your password manager has a built-in generator (1Password, Bitwarden, Apple Passwords all do), use it. The generator pulls from the OS entropy pool — true cryptographic randomness — and lets you pick length and charset.

If you need to generate one outside a password manager, the right primitive in JavaScript is the Web Crypto API:

function randomPassword(length, charset) {
  const bytes = new Uint8Array(length);
  crypto.getRandomValues(bytes);
  let result = '';
  for (let i = 0; i < length; i++) {
    result += charset[bytes[i] % charset.length];
  }
  return result;
}

const charset = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*';
const password = randomPassword(20, charset);

This is what our password generator does internally — Web Crypto API, configurable length and charset, runs entirely in your browser. The password never leaves the page.

The strongest password is the one you never see

System-generated, password-manager-stored, never typed by a human. Length: 20-24. Charset: whatever the system accepts (start with full keyboard, drop classes only if rejected).

Random 4-word diceware passphrases are the exception — they're as strong and far easier to type if you must type the password manually (master password for the manager itself, full-disk encryption boot password, etc.). For everything else: generate, store, paste, forget.

Things that don't help as much as you think

• Character substitutions (p@ssw0rd → P@$$w0rd!). Trivially predicted.
• Forced periodic password changes. NIST 800-63B 2024 also dropped this. It makes users pick worse passwords because they can't remember them.
• Secret questions. Easier to guess or research than the password.
• Knowing the leetspeak alphabet. Same as substitutions; attackers run all common rules.

Things that help a lot

• A password manager (1Password, Bitwarden, Apple Passwords). Removes the reuse problem entirely.
• 2FA / passkeys for every account that supports it. Even a leaked password is useless without the second factor.
• Long, random, per-site passwords. Generate them, store them, forget them.
• For master passwords: diceware passphrases or 20+ character random strings. You'll have to type these — pick what you can type reliably.

Our password generator covers the practical case — generate 16-24 character cryptographically random passwords with configurable charset, in your browser, in bulk if you need them. The math above is why the defaults are what they are.