Password entropy and crack time

The formula, and the two conditions it needs

For a string of L characters drawn independently and uniformly from an alphabet of N distinct symbols, the entropy is H = L x log2(N) bits. A sixteen-character alphanumeric string is 16 x log2(62) = 95.27 bits. A twenty-character password over the 94 printable ASCII characters is 131.09 bits. Thirty-two hexadecimal characters are exactly 128 bits, because log2(16) is exactly 4.

The formula is a compression of two separate claims and both have to hold. H equals the base-two logarithm of the size of the string space, which requires the distribution over that space to be uniform. And the size of the space is N^L, which requires the characters to be independent of one another. Break uniformity and you have modulo bias. Break independence and you have a composition rule. Either one makes the formula overstate the truth, and the overstatement is always in the direction that flatters the tool.

This is also why the formula is honest for machine-generated strings and dishonest for human-chosen ones. NIST moved away from entropy scoring in its password guidance precisely because estimating the entropy of a password a person invented is guesswork. That critique is correct and it does not apply here. When a CSPRNG picks each character uniformly from a known alphabet, L x log2(N) is not an estimate. It is the exact value.

Every option in the generator that reduces the number

Options that feel like they make a password stronger usually make it weaker, because most of them constrain the space rather than expand it. The honest thing for a generator to do is to show the corrected figure rather than the headline one.

A must-include-one-of-each-class rule breaks independence. The correct entropy is L x log2(N) plus log2 of the fraction of strings that satisfy the rule, computed by inclusion and exclusion over the class subsets. The cost is usually small, between roughly 0.01 and 1.1 bits for realistic configurations. It matters much more how the rule is implemented. Generating a string and then overwriting position zero with an uppercase letter and position one with a digit is not uniform and creates a positional pattern that reduces min-entropy further. Generating the whole string, testing it, and discarding and regenerating on failure is exactly uniform over the valid set. The expected number of attempts is 2.17 for eight characters over 94 symbols with four required classes, and 1.064 for sixteen characters over 62. Correctness here costs one extra generation, occasionally.

A no-repeated-characters rule is the expensive one and it is the one users switch on most confidently. The entropy becomes the sum of log2(N - i) over the string, and the loss is 3.059 bits at sixteen characters over 62 symbols, 14.225 bits at thirty-two characters over 62, and 15.119 bits at twenty characters over 26. A generator that offers this toggle and does not adjust the displayed entropy is lying by roughly two characters' worth.

Excluding ambiguous characters is the one that behaves well. It shrinks the alphabet, and that is all it does, so the formula still applies with the smaller N. Going from 62 characters to the 49-character nolookalikes set costs exactly 0.3395 bits per character, which is 5.70%, and is recovered by one extra character per 16.5. A sixteen-character alphanumeric string is 95.267 bits; a seventeen-character nolookalikes string is 95.450. Show people that trade instead of hiding it.

Crack time is a property of the hash, not of the password

Entropy tells you how many candidates an attacker has to try. It says nothing at all about how long one try takes, and that second number varies by seven orders of magnitude across storage schemes in production today.

The rates below are measured, from the Chick3nman benchmark set for hashcat v6.2.6-851 on a single NVIDIA RTX 5090 with optimised kernels. They are a specific tool on a specific card at a specific moment, and they should be read that way rather than as a law of nature.

The same password, six different answers

Expected time to find a uniformly random secret is 2^(H-1) divided by the guess rate, since on average the attacker searches half the space. Applying that to the measured rates gives the table below. The 100,000-GPU column is a well-funded adversary, not a hobbyist, and is included so the numbers do not read as complacent.

Read across the 64-bit row. The same secret is seven minutes on a 100,000-GPU farm against MD5, 1.3 years against MD5 on one card, ten years against SHA2-256, and 959,000 years against bcrypt at cost 5. Against bcrypt at cost 12 it is about 123 million years, which is an extrapolation from the measured cost-5 rate using the algorithm's defined work doubling, 304,800 divided by 128 giving roughly 2,381 hashes per second. That figure is labelled as extrapolated because it is.

The general form of this is worth stating as a rule. The ratio between the MD5 rate and the bcrypt cost-12 rate is 220.6 x 10^9 over 2,381, which is 2^26.47. So a 128-bit secret stored as an unsalted MD5 hash costs an attacker exactly as much work as a 101.5-bit secret stored under bcrypt at cost 12. Choosing a longer password is one lever. Choosing a slower hash is a bigger one, and it is not the user's to pull.

Where the thresholds come from

Strength labels are worth almost nothing unless each boundary is anchored to something you can cite. Ours are anchored to NIST SP 800-63B-4 and to the rate table above, and the number is always shown next to the label because the number is the part that carries information.

Below 32 bits is broken: 2^31 MD5 guesses is about ten milliseconds on one card. A six-digit one-time code sits at 19.93 bits and belongs in this band, which is correct rather than embarrassing, because such codes are safe only in combination with rate limiting and a short lifetime. From 32 to 63 bits is weak, because NIST requires that a secret below 64 bits be rate-limited. From 64 to 79 is moderate, 64 being NIST's floor for a secret that stands on its own without rate limiting. From 80 to 111 is strong. From 112 to 127 is very strong, 112 bits being the minimum random bit generator security strength NIST mandates through SP 800-131A. At 128 bits and above the bar stops, because it matches AES-128 and additional bits buy nothing against brute force.

One last note on composition rules, since a generator has to take a position. NIST SP 800-63B-4 states that verifiers SHALL require at least 15 characters for a password used as a single factor, and that other composition requirements SHALL NOT be imposed. PCI DSS v4.0.1 requirement 8.3.6 goes the other way and asks for numeric and alphabetic characters at a minimum of twelve. Those two are in direct conflict, and 6.0% of uniform sixteen-character alphanumeric strings contain no digit at all and would fail the PCI check. If you need a PCI-compliant mode, it has to enforce the constraint by whole-string rejection rather than hope, and it has to show you the corrected entropy afterwards.

Questions