Password Entropy Math: Why 12 Characters Is the Floor

Password entropy is the number of bits an attacker has to search, and for a random password it's length × log₂(charset size). Twelve characters drawn at random from all 95 printable ASCII characters give 78.8 bits. That's the shortest length that stays out of reach of a 1,000-GPU farm for decades even when the site stored it as unsalted MD5, which is why I treat 12 as the floor for generated passwords. For passwords people pick themselves, the floor is higher: NIST now says 15.

The rest of this article is the reasoning behind both numbers, and the one case where the formula lies to you.

The password entropy formula

H = L × log₂(R)

H is entropy in bits, L the number of characters, R the size of the pool each character is drawn from. A password with H bits has 2^H possible values, and an attacker who tries them all finds it, on average, halfway through.

Per-character values for the common pools:

The table shows why length wins. Moving from letters and digits to the full 95 characters adds log₂(95/62), about 0.62 bits per character: 6.2 bits across a 10-character password. Adding a single character at R = 95 adds 6.57 bits, so on a typical password a composition rule ("at least one symbol") is worth less than one extra keystroke.

Passphrases fit the same formula with words instead of characters. The EFF large wordlist has 7,776 words, so each random word adds log₂(7776) ≈ 12.92 bits, and six words come to 77.5 bits.

How many bits an attacker can actually exhaust

Entropy alone is just a number. It becomes a length recommendation once you compare it with what an attacker can search in a given time. Using the hashcat 6.2.6 benchmark for one RTX 4090 (164.1 billion MD5 guesses per second, about 5,750 per second for bcrypt at cost 10), here's how many bits each setup exhausts in one year:

The first row explains why online attacks don't care about entropy at all. NIST SP 800-63B Rev. 4 caps a verifier at 100 consecutive failed attempts per account, so an online attacker only ever tries the most common passwords. Entropy matters after a breach, when the hash database is on the attacker's own hardware and there's no lockout.

The bottom row is the one I design for. You don't know whether a site uses bcrypt or a bare MD5 from 2012, and a breach can sit in someone's archive for years before anyone cracks it. 72 bits per year for a large farm means anything near that line is a matter of budget, not possibility.

Why 12 random characters is the floor

At 78.8 bits, a random 12-character ASCII password has about 5.4 × 10²³ combinations. Against MD5, that's roughly 104,000 years worst case on one RTX 4090. Rent 1,000 of them and the average crack still takes about 52 years. That's the margin I want against the worst storage I might be trusting.

Ten characters at the same pool gives 65.7 bits. One GPU still needs 11.6 years to try everything, which sounds fine until you scale it: the same 1,000-GPU farm runs the whole keyspace in about four days. Eight characters (52.6 bits) don't survive a single card for a day.

Twelve lowercase letters, a length that often passes "minimum 12" policies, is only 56.4 bits: about a week for one GPU against MD5. The floor is 12 characters from the full pool, not 12 characters of anything.

The full table by length, charset and hash is in how long it takes to crack a password. I won't repeat it here.

Why NIST says 15

NIST SP 800-63B Rev. 4 (2025) sets the minimum at 15 characters when a password is the only authenticator, and 8 when it's paired with MFA. It also tells verifiers to accept at least 64 characters, drop composition rules and forced rotation, and check new passwords against breach and common-password lists.

That isn't a contradiction of the 12-character floor. NIST writes rules for passwords that people choose, where the real entropy is far below what the formula says. Fifteen characters gives a human-chosen password more room to survive dictionary and rule attacks, and the blocklist catches the worst choices. For a generated password, 15 characters from the full pool is 98.5 bits, which is beyond anything in the table above. If a password manager fills it in for you, there's no reason to stop at 12 anyway; I use 16–20.

Entropy describes the process, not the string

The formula assumes every character was picked uniformly at random from the pool. That's true for a generator and false for a person. A password's entropy is a property of how it was made, so you can't measure it by looking at the result.

My own Password Strength Checker is a good example of the limit. It runs entirely in your browser and sends nothing anywhere, and it applies L × log₂(R) to whatever character classes it sees. Give it Password1! and it reports about 65 bits, because it sees upper, lower, digits and a symbol across 10 characters. In reality that string is in every wordlist, and a rule-based attack finds it within the first few thousand guesses. Treat any formula-based score, mine included, as an upper bound that only holds for generated passwords.

Estimators that model human patterns, like Dropbox's zxcvbn, get closer for chosen passwords because they count guesses through dictionaries, keyboard walks and dates instead of characters. They're still estimates.

The practical answer is to stop choosing. A generator gets the full entropy only if its randomness is cryptographic: the Password Generator draws each character from crypto.getRandomValues(), the operating system's CSPRNG. Math.random() in V8 is xorshift128+, and its internal state can be recovered from a handful of outputs, which makes every later "random" password predictable.

What to use

If you're replacing an old password after a leak, the order of steps matters more than the length, and I covered that in what to do after a data breach.

FAQ

How many bits of entropy does a strong password need?

For anything that could end up in a stolen hash database, aim for 75–80 bits or more. One RTX 4090 exhausts about 62 bits per year against MD5, and a 1,000-GPU farm about 72, so 78.8 bits (12 random printable characters) leaves real margin. Online-only protection needs far less, because lockouts limit attackers to about 100 guesses.

Why is 12 characters the minimum password length?

Twelve random characters from all 95 printable characters are the shortest password that a large GPU farm can't exhaust in a reasonable time, even against unsalted MD5. This applies only to generated passwords. A 12-character password you invented may follow a pattern that cracking rules try early.

Does adding special characters help more than adding length?

No. Symbols raise the pool from 62 to 95 characters, which is worth about 0.62 bits per character. One additional character is worth 6.57 bits. If a site forces a symbol, add one, but get your strength from length.

Is password entropy the same as password strength?

Only when the password was generated randomly. For chosen passwords, the formula overestimates badly: Password1! scores about 65 bits on a charset-based meter and falls almost instantly to a wordlist. Strength for chosen passwords depends on how far down an attacker's guess list they sit, not on their character classes.