How Long Should a Password Be? Entropy, Passphrases and Crack Times

The honest answer to “how long should a password be?” is: long enough that guessing it is not worth anyone’s time. That sounds evasive, but it can be made precise. The unit is the bit of entropy, and once you know how to count bits, most password advice either makes sense or visibly falls apart.

What entropy actually measures

Entropy is the base-2 logarithm of how many passwords the process that made yours could have produced. A password picked uniformly at random from 2⁶⁰ possibilities has 60 bits. Each extra bit doubles the work an attacker has to do.

The key word is process. Entropy describes how a password was made, not how it looks. Tr0ub4dor&3 looks random, but it is a dictionary word with predictable substitutions, and cracking tools try exactly those substitutions first. A strength meter that sees mixed case, digits and a symbol will rate it highly. A counting argument will not.

For a random password the count is simple: length × log₂(size of the character set).

Password	Character set	Entropy
4-digit PIN	10	13 bits
8 lowercase letters	26	38 bits
8 characters, full set	90	52 bits
12 characters, full set	90	78 bits
16 characters, full set	90	104 bits
6 words, EFF short list	1,296	62 bits
6 words, EFF long list	7,776	78 bits

Length does most of the work. Going from 8 to 12 characters adds 26 bits, which multiplies the guessing effort by about 67 million. Adding symbols to a lowercase-only password raises the per-character figure from 4.7 bits to 6.5.

Crack time depends on where the attacker is

A number of bits only becomes a time once you know how fast guesses can be made, and that varies by more than a factor of a billion.

Against a live login form, an attacker might get ten guesses a second before rate limiting or lockouts kick in. At that speed even a 4-digit PIN takes about eight minutes on average, and most services lock the account long before then.

Against a leaked database, the attacker has the password hashes on their own hardware and the only limit is the hash function. With a deliberately slow hash such as bcrypt, one high-end graphics card manages something like ten thousand guesses a second. With a fast hash like unsalted MD5 — still found in older systems — the same card manages around a hundred billion.

At a hundred billion guesses a second, the average time to crack is:

Entropy	Example	Average time
38 bits	8 lowercase letters	about a second
52 bits	8 random characters	about 6 hours
62 bits	6 short diceware words	about 9 months
78 bits	12 random characters	about 45,000 years
104 bits	16 random characters	far longer than the universe has existed

This is why the same password can be fine on one site and badly exposed on another. You do not get to choose the hash a site uses, so pick a password that survives the bad case.

How many bits do you need?

A workable rule:

• Under 40 bits — acceptable only behind strict lockouts, such as a phone PIN or a bank card.
• 60 bits and up — fine for everyday accounts, especially when every account has a different password.
• 80 bits and up — for the passwords that protect everything else: a password manager’s master password, disk encryption, your main email.

Generated at random, 60 bits is a 10-character password or a 6-word passphrase, and 80 bits is 13 characters or 8 words.

Passphrases: entropy you can remember

Diceware picks words at random from a fixed list. The EFF’s short list has 1,296 short, common words, so each word adds log₂(1296) ≈ 10.3 bits. Six words — ferry-cloak-rigid-sushi-zebra-ounce — gives 62 bits: roughly a random ten-character password, but far easier to type on a phone keyboard or a TV remote, and much easier to remember.

The words must be chosen at random. A song lyric or a quote has almost no entropy, however long it is, because attackers use lists of those too.

What current guidance says

NIST’s password guidance (SP 800-63B, revision 4) moved away from composition rules years ago, and the current revision is blunt about it. It asks for at least 15 characters when a password is the only thing protecting an account, tells sites not to demand mixtures of character types, and tells them not to force periodic resets. Length and uniqueness matter. Adding a mandatory ! to password does not help.

Two details good generators get right

The Password Generator handles two subtle points that naive generators get wrong.

Modulo bias. Taking a random 32-bit number and computing % 90 makes the first few characters of the set very slightly more likely, because 2³² is not a multiple of 90. The fix is rejection sampling: throw away the few values at the top of the range and draw again.

“At least one of each type.” Many generators force this by inserting one digit and one symbol and shuffling. That skews the output and makes the advertised strength wrong. The cleaner way is to generate the whole password and regenerate if a type is missing. The rule costs less than one bit at normal lengths, and it can be counted exactly.

Where the password is generated matters

A password generated on someone else’s server has, by definition, been seen by that server. A generator that runs in your browser, using crypto.getRandomValues, never sends the result anywhere — you can check the network tab. The same reasoning applies to every tool you paste secrets into, from signing secrets in a webhook verifier to tokens in a JWT decoder; it is set out in full in browser-based developer tools.

The short version

Use a password manager and let it generate a different random password of 16 or more characters for every site. For the few you must remember, use a passphrase of six to eight random words. Ignore strength meters that reward P@ssw0rd!. Count bits instead.

Related reading: private online tools for everyday tasks · debugging JWTs client-side