Password Entropy Explained: The Math Behind Truly Strong Passwords

Entropy is a count of possibilities

Password strength has a precise unit: entropy, measured in bits. Each bit doubles the number of possible passwords an attacker must try. A password with 40 bits of entropy lives in a space of 2⁴⁰ candidates; 60 bits means 2⁶⁰ — a million times larger.

Entropy is not about how the password looks (P@ssw0rd! scores well on the old "uppercase + symbol" checklists and terribly in reality). It measures how unpredictable the selection process was. A password is strong when it was chosen uniformly at random from a large pool — because that maximizes the space an attacker must search.

The formula

For a password of L characters chosen randomly from a pool of R possible characters:

entropy (bits) = L × log₂(R)

The character pool R depends on what the password is allowed to contain:

Every bit of pool expansion adds less than length does: going from 26 to 94 symbols buys you ~1.85 bits per character, while each extra character multiplies the entire search space. This is the mathematical reason length beats complexity.

Worked examples

The Password Generator builds passwords from a stated pool and length, so the entropy is a property of the generator settings — not a hopeful guess. The Password Strength Checker estimates the entropy of a password you already use.

How long would cracking actually take?

Translate bits into time with an explicit attacker model. Offline attack against a stolen password database (the common case — sites store hashes, not passwords, and the attacker guesses against the hash): a plausible 2026 setup is 10¹¹ guesses per second on commodity GPU hardware.

Under that assumption:

Read the table honestly: at 10¹¹/s, 60 bits survives months, not "forever" — and specialized rigs are faster. For credentials that matter, aim for 80 bits and up. Against online guessing (typing into a login form, rate-limited to thousands of attempts per second), even 60 bits is effectively unbreakable — which is why leaked-database attacks are the threat that actually consumes passwords.

Why human-generated passwords fall short

The formula assumes uniform random selection. Humans are terrible random generators, and every pattern shrinks the real pool:

• Tr0ub4dor&3 — looks random, but the substitutions are predictable (a→4, o→0, e→3 are what every cracking rule set tries first). Real entropy: closer to 30 bits than 40.
• Password1!-style patterns — capital first, symbol last, year appended. Cracking tools encode these shapes and search them orders of magnitude faster than raw brute force.
• Reused personal data — birthdays, team names, <site>123. Dictionary + context attacks cover these immediately.

This is why entropy estimated from a human choosing must be discounted from entropy of a uniform draw — the whole point of a generator is that it removes you from the process.

Passphrases: entropy you can memorize

Random words beat random characters per unit of memorability. A diceware-style passphrase draws N words uniformly from a 7,776-word list (6⁵ — five dice per word):

entropy = N × log₂(7776) ≈ N × 12.9 bits

Five words give you the same ~65 bits as 12 random lowercase-and-digit characters — and you can type it on a phone without mashing the symbol key. The rules that keep passphrase entropy honest: the words must be truly random (roll dice or use a generator — your "random" word picks are not), and don't substitute leetspeak or append predictable tweaks, which just adds a false sense of scale.

What NIST's rules follow from the math

NIST SP 800-63B — the US standard that most modern guidance descends from — falls directly out of this model:

• Minimum 8 characters, and allow at least 64 (long passphrases must be legal).
• No composition rules ("must contain a symbol") — they push users toward predictable substitutions that lower real entropy.
• Check against breached-password lists — a leaked password has zero effective entropy regardless of its length.
• No forced periodic rotation without evidence of compromise — rotation pushes Summer2024! → Summer2025!, and predictability is the enemy.
• All printable ASCII and Unicode allowed, spaces included — pool size should not be artificially capped.

Practical rules of thumb

1. Length first. 16+ random characters, or 5+ random words, for anything you care about.
2. Let a generator pick. Human patterns are the vulnerability. The Password Generator draws uniformly from the pool you configure.
3. Unique per site. Entropy is irrelevant if the same password leaks from three sites. A password manager holds the uniqueness; you hold one strong master passphrase (5–6 diceware words).
4. Verify with the Password Strength Checker — it discounts dictionary words and patterns instead of rewarding P@ssw0rd.
5. Where you can't memorize it, you don't have to — for machine credentials, API keys, and WiFi preshared keys, generate 128+ bits with no memorability constraint (a UUID Generator output at 122 random bits, or a long ASCII string, both work).

Entropy gives you something no password "strength meter" from the 2000s can: a number you can reason about. Count the pool, multiply by the length, compare against the attacker's budget — and the vague advice "use a strong password" becomes arithmetic.