Password entropy, length, and character classes: speaking strength in numbers

Apr 26, 2026 6 min read

“Make your password long and complex” is universal advice, but how long and how complex are enough? is a question with an actual numerical answer. This article walks through password entropy and what brute-force resistance looks like in practice.

Entropy: a number for randomness

Password entropy is measured in bits, computed as:

entropy (bit) = log₂(charset_size ^ length)
              = length × log₂(charset_size)

Charset size depends on what characters you allow:

Charset	Characters	Size
Digits only	0-9	10
Lowercase only	a-z	26
Mixed case	A-Z, a-z	52
Alphanumeric	A-Z, a-z, 0-9	62
Alphanumeric + symbols	+ ~32 common ASCII symbols	94
Full ASCII printable	+ remaining symbols	95

Examples:

8-char alphanumeric → 8 × log₂(62) ≈ 47.6 bit
12-char alphanumeric + symbols → 12 × log₂(94) ≈ 78.7 bit

Why bits map to brute-force trials

A password with N bits of entropy needs on average 2^(N-1) trials and at worst 2^N trials to brute-force.

47.6 bit → average 2^46.6 ≈ 1.0 × 10^14 trials
78.7 bit → average 2^77.7 ≈ 2.5 × 10^23 trials

Translating that to wall-clock time, given some hash rate, makes the gap concrete.

Estimated cracking time by hash rate

A single GPU hits roughly 10^10 SHA-256/s in 2026. 100 GPUs in parallel get you 10^12 hashes/s. From there:

Entropy	Charset / length	Avg time at 100-GPU rate
30 bit	9 digits	under 1 second
50 bit	8-char alphanumeric	tens of minutes
70 bit	11-char alphanumeric+sym	decades
80 bit	13-char alphanumeric+sym	thousands of years
100 bit	16-char alphanumeric+sym	exceeds the age of the universe (~10^10 years)

The “practically uncrackable by brute force” threshold is around 80 bits. 100 bits is a comfortable target.

Assumes the server is using a fast hash

Those numbers assume the worst case: the server stores passwords with a fast hash like SHA-256. In reality, password storage should use deliberately slow hashes like bcrypt, scrypt, or Argon2, which can be hundreds to thousands of times slower per check.

Example: bcrypt at cost factor 10 takes about 0.1 seconds per hash. Even with 100 GPUs you only get ~10^6 hashes/s. A 50-bit password becomes practical in this setting — but if a database leak occurs and an attacker spends weeks of compute on offline cracking, the entropy gap matters again.

Why length beats complexity

Look at the entropy formula length × log₂(charset):

Charset 26 → 94: log₂(26) ≈ 4.7 to log₂(94) ≈ 6.55 — about 1.4×
Length 8 → 16: entropy doubles — 2×

Length scales linearly; adding character classes scales logarithmically. “12 characters of plain alphanumeric” beats “8 characters with symbols”.

This is why modern guidance favors length over complexity. NIST SP 800-63B (2017 revision) explicitly moved away from mandatory complexity rules in favor of longer minimums.

Where humans hit the wall: passphrases

The longest “random” password a person can reliably memorize tops out around 12–14 characters — roughly 80 bits.

To exceed that, passphrases (random words from a dictionary) are the practical option:

4 random words from a 10,000-word list = 4 × log₂(10000) ≈ 53 bits
6 words ≈ 80 bits

The famous XKCD strip “correct horse battery staple” gives about 44 bits, which is on the weaker side by today’s standards. 6 words is the modern recommended minimum for memorable passphrases.

A note on strength meters

The strength meters you see on signup forms vary widely in quality:

zxcvbn (originally from Dropbox) — detects dictionary words, keyboard runs, repetition. Reasonably accurate.
Naive class checks — “contains upper, lower, digit, symbol?“. Tends to over-rate weak patterns.
Length-only meters — too simplistic.

A site that accepts Aa1!aaaa as “strong” is using a meter that doesn’t reflect real entropy. zxcvbn or equivalent is the right baseline.

Strength by length: the comparison people actually search

Many users specifically search “12 character password”, “16 character password”, etc. Here is the strength of each length using a 94-character set (uppercase + lowercase + digits + symbols):

Length	Entropy	Brute-force time (10¹² guesses/sec)	Typical use
6 chars	~39 bit	minutes	temporary PIN only (not recommended)
8 chars	~52 bit	days	legacy standard, weak by modern standards
10 chars	~65 bit	years	minimum for general use
12 chars	~78 bit	centuries	general standard
14 chars	~91 bit	tens of millennia	important accounts
16 chars	~104 bit	tens of millions of years	crypto-key-equivalent strength
20 chars	~130 bit	effectively unbreakable	Wi-Fi passphrases
32 chars	~209 bit	physically impossible	API keys, secrets

Practical takeaways:

16 characters is the modern reasonable line — NIST SP 800-63B recommends 12+ characters and emphasizes length over complexity
14 characters is still practically strong enough — useful when Wi-Fi or other systems impose tighter limits
8 characters is risky — it was the old standard, but modern GPU attacks can crack it in days

These times all assume the server uses a slow hash like bcrypt or argon2. With MD5 or SHA-1, all numbers shrink by orders of magnitude.

Practical targets

Use case	Recommended entropy	Example (alphanumeric+symbols)
Throwaway account	≥ 50 bit	8 chars
General use	≥ 70 bit	11 chars
Important / encryption	≥ 100 bit	16+ chars
Machine-generated (API keys, etc.)	≥ 128 bit	22+ base64 chars

For passwords you have to remember, use a passphrase of 6+ random words. For everything else, let a password generator pick.

Password strength gets discussed in vague terms, but bits of entropy let you compare “16-char with mixed character classes” against “8-word passphrase” objectively. The password generator on this site shows the entropy as you tune length and character classes, so you can see what you’re actually getting. Real-world use still assumes a password manager — human memory caps the achievable strength regardless of generator output.