Password strength: what entropy actually measures

A password's strength is not a feeling. It is a number: how many guesses an attacker needs before they are more likely than not to have found it.

Entropy in one formula

Entropy in bits is length x log2(pool size).

A 12-character password from lowercase letters only draws from a pool of 26, so 12 x log2(26) = about 56 bits. The same length using upper, lower, digits and symbols draws from about 90, giving 78 bits.

Now compare that to simply making it longer. Twenty lowercase characters is 94 bits - stronger than the twelve-character password with every character class enabled.

That is the whole argument for length over complexity. Each extra character multiplies the search space by the pool size; adding a symbol class only widens the base.

What the numbers mean

• Under 50 bits - falls to a determined offline attack against a leaked hash.
• 60 bits - adequate for a low-value account behind rate limiting.
• 80 bits - beyond realistic offline cracking with current hardware.
• 100+ bits - not going to be guessed, ever, by anyone.

These assume the password is genuinely random. Entropy calculations describe the generation process, not the string. Tr0ub4dor&3 looks like 11 characters of high complexity and is worth about 28 bits, because it was produced by a predictable set of substitutions applied to a dictionary word.

The advice that got reversed

NIST's 2017 revision to SP 800-63B dropped two rules that had been near-universal:

Scheduled rotation. Forcing a change every 90 days produced Summer2024! followed by Autumn2024!. Predictable increments are worse than a strong password left alone. Change a password when there is a reason - a breach, a shared device, a departing employee.

Composition rules. Requiring one of each character class narrows the search space rather than widening it, because everyone satisfies it the same way: capital at the start, digit and exclamation mark at the end.

What replaced them: a long minimum, a check against known-breached password lists, and no arbitrary maximum length. A service that caps your password at 16 characters is telling you something about how it stores them.

Passphrases

Four or five random words from a large list - the Diceware approach - gives roughly 12.9 bits per word. Four words is about 52 bits, six is 77.

Passphrases are for what you must memorise: a device login, a password manager master key. Everything else should be long random strings that a manager holds and you never see. The point of a manager is that only one credential needs to be memorable.

The word list has to be random. Choosing four words yourself produces something closer to a phrase than a passphrase, and phrase-shaped guesses are exactly what modern cracking rules generate first.

Where randomness comes from

Math.random() is not a security primitive. It is seeded predictably and its output can be reconstructed from a handful of samples.

Use crypto.getRandomValues in the browser, crypto.randomBytes in Node, secrets in Python. Anything generating credentials, tokens or reset links must use a cryptographically secure source, and the difference is invisible until it is exploited.

Also watch the modulo bias: taking a random 32-bit integer modulo a 90-character pool skews slightly toward the early characters. It is a small effect and easy to avoid by rejecting values above the largest clean multiple.

What a password cannot do

None of this helps against a phishing page that receives the password directly, or a service that stores it badly and gets breached.

Two-factor authentication covers the first case, and a passkey or hardware key covers it completely, because there is no shared secret to phish. Unique passwords per site cover the second, which is the actual reason to use a manager - not strength, but the fact that a breach at one service stays at that service.

Generate one with the password generator, which uses the Web Crypto API and shows the entropy figure for whatever settings you pick.