Password Strength and Entropy — What the Numbers Actually Mean

The password strength meter on most sign-up forms is lying to you. Not maliciously — it's just measuring something irrelevant to how passwords actually get cracked in 2026.

The strong opinion: length beats complexity, passphrases beat randomness, and the "add a special character!!" rule is actively bad advice. The reason has to do with how modern cracking tools work, which has almost nothing to do with the "a-z, A-Z, 0-9, symbols" character-class math most sign-up forms are enforcing.

Here is what the numbers actually mean, and the password strategy that would survive the next decade.

Entropy, in one paragraph

Entropy is a measure of unpredictability, measured in bits. A password with 80 bits of entropy, chosen uniformly at random, requires on average 2^79 guesses to crack. That's about 600 quintillion attempts. At 1 trillion guesses per second (achievable with modern GPU clusters), that's about 20 years of continuous cracking for the average password of that strength.

The scale, laid out:

| Entropy (bits) | Guesses needed (avg) | Time at 1T/s | |---|---|---| | 40 | ~500 billion | 8 minutes | | 50 | ~500 trillion | 6 days | | 60 | ~500 quadrillion | 17 years | | 80 | ~600 quintillion | 20,000 years | | 100 | ~600 septillion | 20 billion years |

The thresholds that matter in practice:

• < 50 bits: cracked within a week on modern hardware. Treat as "basically plaintext."
• 50–80 bits: safe against most threats, but not against a determined attacker with cloud GPU budget.
• 80–100 bits: safe against essentially all current adversaries, including state actors.
• > 100 bits: paranoia zone. Useful only when the thing you're protecting is worth billions and lives decades.

The thing nobody tells you about entropy

The entropy of a password is the entropy of how you chose it, not of the string itself.

If I pick correct horse battery staple because it's a specific sequence I thought of after reading XKCD, that specific password has roughly zero bits of entropy against an attacker who knows I read XKCD. Everyone copied it after that comic ran. It's in every wordlist.

If I pick four words uniformly at random from a 7,776-word list (the EFF large wordlist), I get log2(7776^4) = 51.7 bits of entropy. That's the real number. The password string is identical in appearance to someone copying from XKCD. The entropy is wildly different.

This matters because:

• A long password you reasoned about is weak.
• A long password you randomly generated is strong.
• A short random password is weaker than a long chosen-looking one, but only against humans; against machines, random always wins.

For passwords that are actually random, the Random Password Generator uses CSPRNG-backed selection — the entropy of the output equals the entropy of the generation, no hidden bias from human choice.

The "add a special character" lie

The reason sign-up forms demand uppercase/lowercase/number/symbol is pure character-space math. If your password alphabet is 72 characters wide (not just 26), each character carries log2(72) = 6.17 bits instead of log2(26) = 4.7 bits. So an 8-character password has 49 bits of entropy if drawn from the full 72-character alphabet versus 38 bits from lowercase alone.

Problem: humans don't comply with the policy by expanding their character choice. They comply by taking "password" and making it "Password1!" — which, against a cracker tuned for human policies, is barely harder than "password" (which it will try first) and much easier than a random 8-character lowercase string.

Attackers in 2026 use templates like Capitalized_word + Common_number + Common_symbol. These patterns cover 90% of what sign-up-rule-compliant humans produce. The entropy is close to the entropy of just the base word, which is log2(10000) ≈ 13 bits — crackable in milliseconds.

The sign-up-rule approach to passwords has been actively harmful. NIST updated its guidance in 2017 to say: stop requiring arbitrary complexity, allow long passwords (64+ chars), and screen against known-breached passwords instead. Most sign-up forms still haven't caught up.

Why passphrases work

A random 4-word passphrase from a 7,776-word list = 51.7 bits. A random 6-word passphrase = 77.5 bits. A random 8-word passphrase = 103 bits.

Six words gets you past "safe against state actors" territory. Humans can remember six words. Humans cannot remember a 16-character random string.

For a passphrase-pattern password, the Fake Password Generator demonstrates the register you want for the real article — pronounceable chunks, memorable rhythms, entropy from length rather than symbol-density. The Random Password Words Generator focuses specifically on the word-list half of the problem.

The honest trade-off: passphrases are long. Login forms that limit passwords to 20 characters are not passphrase-friendly. If your main system allows it, use passphrases. If it doesn't, use the longest random string the field permits (and complain to the vendor).

How cracking actually works in 2026

The naive "try every 8-character password" is not what attackers do. The real pipeline:

1. Breach databases first. If your email appears in a breach, every password you ever used anywhere is on a wordlist. The attacker tries those before anything else. 2. Mangle those passwords. Try the breach password with 1-9 appended, with ! appended, with capital first letter, with l33t speak substitutions. Hashcat has prebuilt rules for every common mangling. 3. Try common wordlists. Rockyou.txt (14M passwords from a 2009 breach) is still the first-pass dictionary. Then language-specific wordlists. 4. Try common patterns. Firstname_YYYY, Companyname_123, keyboard walks (qwerty, 1qaz2wsx). 5. Only then try brute force. By which point they've already cracked 60–80% of the typical password dump.

Implications for choosing your password:

• Reusing a password anywhere is strictly worse than any other choice, because step 1 above cracks you immediately on step 2's first attempt.
• Making a password that follows a recognisable human pattern (any pattern) hands it to the mangling rules.
• Entropy against brute force only matters for passwords that survive steps 1–4. Which they do only if they're randomly generated and never reused.

Password managers are the only real answer

Everything about human-chosen passwords is a losing fight. The architecture that works:

1. One master passphrase (random, 6+ words from a wordlist). Stored only in your head. 2. All other passwords: random, generated by the password manager, 20+ characters, mixed character classes. You never type them.

The master passphrase has to be strong because it's the only thing between the attacker and all your other credentials. Hence 6-word minimum (77.5 bits).

Everything else is machine-generated and copy-pasted, so there's no cognitive cost to it being 9Yz!8qLm2pR4@xV7bN3k. The strength of these is irrelevant to usability.

For generating these high-entropy strings, the Random Password Generator is tuned for this register. For when you want to see the alternative pattern — a shorter string with specific entropy properties — the Fake Password Generator demonstrates the shape.

2FA and password strength are not interchangeable

A common fallacy: "I have 2FA, so my password doesn't need to be strong."

Partially true, partially dangerous. 2FA defends against stolen-credential attacks: someone has your password but not your phone, they can't log in. 2FA does NOT defend against:

• Password managers getting breached (if the master passphrase is weak).
• SIM-swap attacks (SMS 2FA is bypassed by social-engineering the carrier).
• Session cookie theft (once you're logged in, 2FA doesn't re-verify every action).
• Phishing attacks that proxy the real 2FA prompt in real time.

Use 2FA. Also use strong passwords. They defend against different attacks.

The specific policies I follow

For my own accounts in 2026:

1. Master passphrase: 7 random words from the EFF wordlist. 90 bits of entropy. Memorised. Never typed on a device I don't trust. 2. Everything else: generated by my password manager, 24-character random with full character classes. Entropy ~155 bits. Unique per site. 3. 2FA: hardware key (YubiKey) for anything sensitive, TOTP app for everything else, SMS only if there's no other option. 4. Breach monitoring: a weekly scan against haveibeenpwned. Any password that appears gets rotated immediately. 5. "Secret questions" fields: filled with random generated strings, treated as additional passwords. The honest answer to "mother's maiden name" is almost certainly a public record; the random string is better security.

The thing most people get wrong is the fourth item. If you don't check for breaches, you don't know you need to rotate. A password that was strong when you made it is cracked the moment it appears in a breach dump.

The one gotcha with password strength meters

Most strength meters (zxcvbn and derivatives) are much better than the "character class checklist" approach. They actually estimate the number of guesses a cracking tool would need, accounting for dictionary words, keyboard patterns, common substitutions, year patterns, and more.

But they still have blind spots:

• They don't know about leaked breaches. A password that's "strong" by their math but is in the top 1000 of the 2024 breach dump is weak in reality.
• They don't know about targeted attacks. "MyDogRex2015" rates reasonably in a generic strength meter and is trivial for someone who knows your dog's name and the year you got him.
• They don't know your other passwords. "MyDogRex2015" and "MyCatSal2017" look independent to the meter; to an attacker who cracks one, the other falls in seconds.

Use the meters as a floor, not a ceiling. "This meter says my password is strong" means "this password is probably not catastrophically weak" and not much more.

Minimum viable password hygiene

For a technical reader who doesn't use a password manager yet, in order of highest-value-first:

1. Install a password manager. Any mainstream one is fine. Bitwarden if you want open source and free. 2. Enable 2FA on your email account. Email is the recovery vector for every other account. 3. Change your email password to a random 20+ character string from the manager. 4. Enable 2FA on your password manager. 5. Over the next month, replace your 20 most-used passwords with manager-generated randoms. 6. For the rest, let them get replaced as you log into them.

Six steps. The result is the architecture that defeats 99% of real-world attacks. The remaining 1% is targeted attacks by well-funded adversaries, and no password choice will save you from those — the defense there is operational security, not entropy.

The security of your digital life is almost entirely determined by step 1. Everything else is marginal. If you only do one of the six, do the first one.

Entropy budgets for things that aren't passwords

Password-shaped strings show up in a lot of places that aren't passwords. Each has its own entropy budget worth understanding:

Session tokens / API keys. 128 bits of entropy is the floor. Anything less is theoretically crackable by a motivated attacker with cloud resources. 256 bits is the comfortable upper bound. Generated by crypto.randomBytes(16) for 128 bits or crypto.randomBytes(32) for 256. The Fake API Key Generator emits strings at this length for prototype work.

Password reset tokens. 128 bits is fine, but they should also expire. A 128-bit reset token that lives for 24 hours is a different threat model than one that lives for 30 days. The expiration is doing as much security work as the entropy.

Short confirmation codes (SMS verify, email codes). 20 bits is the usual floor — a 6-digit numeric code is 19.9 bits. These rely on short expiration and rate-limiting to resist brute force; a 6-digit code with no rate limit is 1,000,000 guesses, trivially broken. Pair the entropy with "lock after 5 wrong attempts" and the effective security is much higher.

Nonce / CSRF values. 128 bits, generated per request. The threat model is replay; entropy is table stakes but not the whole defense.

Encryption keys. 256 bits for AES-256. Not generated by any text-generator tool; use the OS CSPRNG via your language's crypto library. The UUID v4 Generator outputs 122 bits of entropy per UUID — close to the floor for session tokens, below the floor for encryption keys. Different jobs, different tools.

The pattern: entropy requirements track what the token is defending against. Passwords are defending against persistent offline cracking; session tokens defend against online guessing with rate limits; confirmation codes defend against immediate replay with aggressive expiry. One budget doesn't fit all.