For decades, sites demanded an uppercase, a number, and a symbol. The math says length matters far more — and the modern standards agree. Here's why, with the entropy numbers laid out.

Published: 2026-08-21By: Toolhub Admin · About the author

For twenty-odd years, signing up for anything meant obeying the same ritual: at least eight characters, one uppercase, one lowercase, one number, and one special symbol. The rules felt rigorous. They were mostly theatre. A password like P@ssw0rd! ticks every box and is one of the first things any cracking tool tries. Meanwhile correct horse battery staple — four plain lowercase words — breaks none of the rules on many sites and is dramatically harder to guess.

The reason comes down to one measurable quantity: entropy. Once you can estimate the entropy of a password, the length-versus-complexity argument stops being an opinion and becomes arithmetic. This article works through that math, explains why forced complexity rules backfire, summarises what the current standards actually recommend, and covers how the password you type gets protected once it lands on a server.

Entropy is the number that matters

Password strength is really a measure of how many guesses an attacker has to make, on average, to hit yours. That is entropy, measured in bits. Each bit doubles the number of possible passwords. The formula for a randomly generated password is simple:

bits = length × log2(alphabet size)

The alphabet size is how many distinct characters could appear in each position. Lowercase letters alone give 26. Add uppercase and you have 52. Add digits, 62. Add a set of common symbols, roughly 95 printable ASCII characters. The log2 of the alphabet size tells you how many bits each individual character contributes:

Here is the crucial observation. Moving from lowercase-only to the full symbol set raises the per-character contribution from 4.70 to 6.57 bits — a gain of under 40%. Adding a single character to the length adds a full character's worth of bits regardless. Length is a multiplier on the whole thing; complexity only nudges one factor inside it.

The entropy table

The numbers below assume random generation from the stated alphabet. Real human-chosen passwords have far less entropy than their length and alphabet suggest, which is a separate problem addressed later. Read this as the theoretical ceiling.

Length Lower (26) Alnum mixed (62) Full ASCII (95)
8 chars~38 bits~48 bits~53 bits
12 chars~56 bits~71 bits~79 bits
16 chars~75 bits~95 bits~105 bits
20 chars~94 bits~119 bits~131 bits
24 chars~113 bits~143 bits~158 bits

Look down the table rather than across it. A 20-character lowercase-only password (~94 bits) beats a 12-character full-ASCII password (~79 bits), despite using the smallest possible alphabet. Length wins the fight even when it fights with one hand tied. To put the top-left against the bottom-right: going from 8 lowercase characters to 24 more than quadruples the bit count, whereas widening the alphabet at fixed length never even doubles it.

The passphrase argument

This is where the famous "correct horse battery staple" idea comes from — a webcomic that captured a real point. A passphrase of several random common words is easier for a human to remember and can carry more entropy than a short scrambled string, because you can make it long without pain.

The entropy of a random-word passphrase is computed per word, not per character: bits = number of words × log2(size of word list). A widely used word list, the EFF long list, contains 7,776 words, giving log2(7776) ≈ 12.9 bits per word. So:

The catch that people miss: this only holds if the words are chosen randomly, ideally by dice or a generator. Picking a memorable phrase from a song lyric or a common saying collapses the entropy, because an attacker guesses phrases, not independent words.

Why forced complexity rules backfire

The theory says complexity adds a little entropy. In practice, mandatory composition rules often reduce real-world strength, because humans satisfy them in predictable ways. Told to add an uppercase, most people capitalise the first letter. Told to add a number, they append 1 or the current year at the end. Told to add a symbol, they use !. Told to substitute, they turn a into @ and s into $.

Cracking tools know all of this. Modern password crackers apply exactly these transformation rules on top of dictionary words, so Password1! and P@ssw0rd offer almost no resistance despite passing every complexity check. The rules push the entire user base toward a small, well-known region of the search space — the opposite of the intent.

What the modern standards actually say

The guidance that shaped the old rules changed years ago. NIST Special Publication 800-63B, the U.S. federal digital identity guidelines, now recommends a markedly different posture for password ("memorized secret") verifiers:

The through-line is that these standards optimise for the passwords real people and their tools actually produce, not for a checklist that looks strict on paper.

What happens after you type it: hashing

Entropy protects against guessing. It does nothing if the server stores your password in plain text and then gets breached. That is where hashing comes in, and it is worth understanding the distinction.

A well-designed system never stores your password. It stores the output of a one-way password hashing function — bcrypt, scrypt, or Argon2 — applied to your password plus a random salt unique to each account. The salt ensures two users with the same password get different stored hashes, defeating precomputed "rainbow table" lookups. These functions are also deliberately slow and, in Argon2's case, memory-hard, so that testing billions of guesses becomes expensive even with specialised hardware. This is a different job from fast general-purpose hashes such as SHA-256, which are the wrong tool for storing passwords precisely because they are fast.

The order-of-magnitude takeaway: an attacker who steals a database of bcrypt or Argon2 hashes still has to guess each password one slow attempt at a time. Against a strong, high-entropy password, that is the difference between a breach that leaks your credentials and one that merely leaks an unusable hash.

Tool walkthrough

Toolhub's password generator is built around the length-first principle. It creates long, genuinely random strings or word-based passphrases in the browser, lets you dial the length up rather than fussing over which symbol classes to force, and reports the resulting entropy in bits so the numbers in this article stop being abstract. Generate at 16 or more characters, or four-plus random words for something you have to memorise, and let a password manager hold the rest.

The hash generator is a companion for understanding how hash functions behave — feed it text and watch how a one-character change produces a completely different SHA-256 digest, and how the same input always yields the same output. Treat it as a learning tool for how hashing works, not as a way to hash real passwords: production password storage needs a salted, deliberately slow function like bcrypt or Argon2 running on the server, never a fast hash computed in a browser tab.

Where to read further

The old advice had it backwards. Complexity rules produced passwords that were hard for humans to remember and easy for machines to guess. The math is unambiguous: add length, prefer a random passphrase you can actually recall, screen against known breaches, and let hashing do its job on the server. Strength comes from the number of guesses an attacker must make — and length is the cheapest way to make that number enormous.

← All articles