How strong is your password, really?

Two passwords. The first is P@ssw0rd! — uppercase, lowercase, a digit, a symbol, every box on the signup form ticked. The second is correct horse battery staple — four ordinary lowercase words. Most people would guess the first is stronger. They'd be badly wrong: the second is millions of times harder to crack.

The reason is entropy. Password strength has a real, measurable unit, and it isn't "number of character types." It's the number of bits of genuine unpredictability in the password. Once you can estimate that number, every password argument you've ever had resolves itself.

What "strength" actually measures.

Entropy is a measure of how many equally-likely possibilities a value was drawn from, expressed as a power of two. One bit of entropy means two possibilities; ten bits means 2¹⁰ = 1,024; twenty bits means just over a million. A password's entropy is how many such bits an attacker has to chew through, on average, to guess it — assuming they know exactly how it was generated but not the random choices that went into it.

The crucial word is generated. Entropy lives in the process that produced the password, not in the characters you can see. aaaaaaaa and a random eight-character string look equally arbitrary to you, but if the first came from "press A eight times" it has almost no entropy. This is why "how strong is this specific password?" is the wrong question — strength is a property of how it was chosen.

The math, in one line.

For a password of L characters, each chosen independently and uniformly at random from an alphabet of N symbols, the entropy is:

bits = L × log₂(N)

That's the whole thing. log₂(N) is the bits each character contributes; multiply by how many characters you have. The common alphabets:

Alphabet	N	Bits per character
digits only	10	3.32
lowercase letters	26	4.70
letters + digits	62	5.95
letters + digits + ~30 symbols	94	6.55

So a random 12-character password using the full 94-symbol keyboard is 12 × 6.55 ≈ 79 bits. A random 16-character lowercase-only password is 16 × 4.70 ≈ 75 bits — almost the same, with none of the symbols. That near-tie is the entire length-versus-complexity argument, sitting in one equation.

Why length beats complexity.

Adding symbols raises log₂(N), but only a little — going from 62 to 94 symbols buys you 0.6 extra bits per character. Adding length multiplies the bits you already have. Because bits are exponential, each one doubles the attacker's work, so the cheapest way to buy a lot of doublings is to add characters, not character types.

Concretely: a 10-character password with every symbol class enabled is about 66 bits. A 14-character all-lowercase password is about 66 bits too — identical strength, far easier to type and remember. Push to 20 lowercase characters and you're at 94 bits, well past what the symbol-soup password achieves. Length is the lever; complexity is a trim tab.

What the bits mean in real cracking time.

Bits only matter relative to how fast someone can guess. The dangerous scenario isn't an attacker typing into a login form (rate-limited, slow) — it's an attacker who has stolen a database of password hashes and is guessing offline, on their own hardware, as fast as the hash allows.

For a fast, poorly-chosen hash, a single modern GPU rig can try on the order of 10¹⁰–10¹¹ guesses per second; a well-funded attacker can stack many. As a rough mental model, brute-forcing n bits takes about 2ⁿ⁻¹ guesses on average:

Entropy	Average guesses	At ~10¹⁰/s (one fast rig)
40 bits	~5 × 10¹¹	under a minute
56 bits	~3.6 × 10¹⁶	~weeks
72 bits	~2.4 × 10²¹	~thousands of years
96 bits	~4 × 10²⁸	longer than the universe has existed

This is why the rough guidance is: under 40 bits is weak (it falls in seconds to minutes offline), around 60 is fair, 72–80 is strong for almost any individual account, and 100+ is "encryption-key" territory you only need for things that must resist attackers for decades. A slow hash (bcrypt, scrypt, Argon2) shifts every row dramatically toward "safe" — which is the defender's other lever, and why the hash choice matters as much as the password.

Why human-chosen passwords leak entropy.

The formula assumes every character is chosen uniformly at random. Humans don't do that. We pick words, names, dates, and keyboard patterns; we capitalize the first letter, put the digit and the symbol at the end, and substitute @ for a. Attackers know all of this and bake it into their guessing order, so a "complex-looking" human password has far less effective entropy than its length and alphabet suggest.

P@ssw0rd! has nine characters from a 94-symbol alphabet — about 59 bits if it were random. But it's a dictionary word with the four most predictable substitutions on the planet, so a cracking tool's rule engine tries it almost immediately; its real entropy is a handful of bits. The lesson isn't "add more substitutions." It's that the only reliable way to get the entropy the formula promises is to let a machine make the random choices — which is exactly what a generator does.

Passphrases: entropy you can remember.

If you have to memorize a password, random characters are miserable. Passphrases solve this: pick several words at random from a known list and the entropy is (number of words) × log₂(list size). The classic Diceware list has 7,776 words, so each random word is log₂(7776) ≈ 12.9 bits. Four words ≈ 52 bits, five ≈ 65, six ≈ 77 — strong, and far easier to remember than a 13-character symbol jumble of the same strength.

The catch is the same as before: the words must be chosen by something random, not by you. "battery horse staple" picked because they feel random is not random. A generator (or actual dice) is what makes the entropy real.

Takeaways.

The reason "P@ssw0rd!" feels strong and "correct horse battery staple" feels weak is that our intuition tracks visual complexity, and complexity is not the unit. Bits are. Once you measure in bits, the safe choices are also the comfortable ones: longer, simpler, and machine-random.