Understanding passwords
Entropy beats cleverness.
Why long random strings are stronger than short complicated ones — and how to measure that, in bits.
Entropy, in one number.
Password strength is measured in bits of entropy — how many binary guesses an attacker would need before stumbling on yours. A truly random password drawn from an alphabet of size N has log₂(N) bits of entropy per character. Lower-case alone gives 4.7 bits. Mixed case plus digits gives 5.95. Mixed case, digits and symbols across a 95- character alphabet gives 6.55. Multiply by length to get the total.
entropy ≈ length × log₂(alphabet)
Length wins.
A twelve-character password from the 95-character keyboard set has about 78 bits of entropy. A sixteen-character version of the same has 105. A passphrase of six random words from a large word list has about 78 bits — and is far easier to type. Adding symbols matters less than people think; adding length matters more. The reason the security advice changed in the last decade is exactly this: complexity rules pushed people toward short passwords with predictable substitutions. Length is what eats the search space.
Two passwords, two budgets
alphabet 95, length 8 vs 16
Doubling length squares the search space.
95⁸ ≈ 6.6 × 10¹⁵ 95¹⁶ ≈ 4.4 × 10³¹
= ≈ 16 quadrillion vs 44 nonillion
Why "P@ssw0rd!" is bad.
The number of bits of entropy assumes the choice is random. Real humans pick from a much smaller set: dictionary words, common substitutions (a → @, o → 0, e → 3), a digit at the end, an exclamation mark. Cracking tools encode all of those rules and rip through them in milliseconds. P@ssw0rd! has ten characters and would suggest 65 bits of entropy if it were random; against a real attacker, it's worth maybe 12.
Where to store them.
The only sustainable answer for a human with thirty accounts is a password manager. Generate a long random password per site, let the manager autofill it, and concentrate your memorisation on one strong master password plus a second factor. Nothing else scales — and nothing else lets you make every site's credential independent, so a breach at one doesn't burn the rest.
What the server should be doing.
On the server side, never store a raw password. Hash it with a dedicated password-hashing function — Argon2id, scrypt, or bcrypt — that's deliberately slow and tunable. A well-tuned parameter set keeps a single guess to 100 ms or so, which is imperceptible to a user logging in but ruinous for an attacker trying billions. SHA-256 is the wrong choice here precisely because it's fast.
Two-factor closes the gap.
Even a strong password leaks sometimes — phishing, malware on a friend's device, a database breach. A second factor (a TOTP app, a hardware key) means the attacker needs more than the password. Hardware keys backed by WebAuthn are the most phishing-resistant option because the key cryptographically binds itself to the original site's domain; a fake login page can't ask for the right ceremony.
Read next