Password Entropy Explained

For a password of random characters, entropy is H = L × log₂(N), where L is the length and N is the number of possible characters at each position. The log₂(N) part is the number of bits each character contributes: lowercase letters (N=26) give about 4.7 bits each, adding uppercase and digits (N=62) gives about 5.95, and a full symbol set (N≈95) gives about 6.57. Multiply by the length and you have the total.

Crucially, this formula assumes each character is chosen randomly and independently. A password you invented yourself has far less effective entropy than the formula suggests, because your choices follow patterns an attacker can model. Entropy math only tells the truth when the randomness is real.

A worked example makes the trade-offs visible. Sixteen characters from the 94 printable ASCII symbols is 16 × 6.55 ≈ 105 bits. The same sixteen characters restricted to letters and digits is 16 × 5.95 ≈ 95 bits, so every punctuation mark on the keyboard was worth about ten bits in total — roughly one and a half extra characters. Length wins that comparison every time it is offered.

Each bit of entropy doubles the number of guesses required. 40 bits means about a trillion possibilities — crackable in minutes today. 60 bits is measured in years for a serious attacker; 80 bits is comfortably out of reach for almost everyone; and 100+ bits is effectively uncrackable with any foreseeable technology. As a practical target, aim for 80 bits on ordinary accounts and 100 or more on the ones that matter most.

Anchoring the bits to a guessing rate makes them concrete. At ten billion guesses per second — one strong GPU against a fast hash — walking the whole of a 40-bit space takes under two minutes, a 60-bit space takes about three and a half years, and an 80-bit space takes roughly four million years. Every additional ten bits multiplies the time by a little over a thousand, which is why the step from 60 to 80 bits changes the answer from 'eventually' to 'no'.

A crack-time figure turns entropy into something intuitive by assuming a guessing rate — PassVault uses ten billion guesses per second, a reasonable figure for an offline GPU attack against a fast hash. Remember it is a worst-case, order-of-magnitude estimate: a slow hash like bcrypt or Argon2 makes attacks thousands of times slower, while a stolen unsalted hash could be faster. The exact seconds matter less than the ballpark — 'centuries' is a pass, 'hours' is not.

It is worth spelling out everything such a number assumes: that the attacker already holds the hash, that they know the character set and the length, and that no shortcut exists because there is no pattern to exploit. Above all, it assumes the search proceeds uniformly — and against a password that came out of a person's head rather than a generator, no attacker searches uniformly. They try the likely things first.

Entropy in the strict sense is a property of the process that produced a password, not of the string itself, so a checker handed nothing but the string has to guess how it was made. Tools such as zxcvbn take the practical route: they match the input against dictionaries, names, dates, keyboard walks and l33t substitutions, then report roughly how many guesses the cheapest matching strategy would need. The result is often far below the naive formula — the famous 'Tr0ub4dor&3' scores around 28 bits rather than the 72 its shape implies.

For genuinely random output the two approaches converge, because no strategy is cheaper than brute force and the pattern matchers find nothing to grip. If a strength meter and the formula agree on a password, the randomness behind it is probably real.

The other half of any estimate belongs to the service, in the shape of the function it stores your password through. A purpose-built slow hash — bcrypt at cost 12, scrypt, or Argon2id with tens of mebibytes of memory and a couple of passes — costs an attacker milliseconds of work per guess per core instead of nanoseconds. That is the difference between ten billion guesses per second and a few thousand, and it is worth roughly twenty bits of free entropy on top of whatever your password already has.

Salting matters too, though in a different way. A unique random salt per password does not slow a single guess down at all; it stops the attacker from testing one guess against every account in the table simultaneously, and it makes precomputed rainbow tables useless. An unsalted MD5 dump is the worst case on both counts: billions of guesses per second, each one amortised across the entire user base. PBKDF2 sits in between — cheap enough to run on a GPU that current guidance sets its iteration count in the hundreds of thousands to compensate.