For twenty years the standard advice was to use a short password with mixed case, a number, and a symbol. That guidance produced predictable passwords that were hard for humans to remember and easy for software to guess. Both halves of that failure are worth understanding.
Entropy is the actual measure
Password strength is measured in bits of entropy, which is a formal way of asking: how many guesses would an attacker need? The calculation is straightforward — the size of the character set, raised to the power of the length.
- An 8-character password from 95 printable ASCII characters gives about 52 bits.
- A 16-character password from lowercase letters alone gives about 75 bits.
- A 20-character password from the full ASCII set gives about 131 bits.
Notice what that second line means. Sixteen lowercase letters — no capitals, no digits, no symbols — is dramatically stronger than eight characters using everything. Length is an exponent; character variety is only the base. Adding characters wins every time.
Why complexity rules backfired
When a system demands one uppercase, one digit, and one symbol, people respond in remarkably uniform ways. The capital goes at the front. The digit and symbol go at the end. The digit is often 1, and the symbol is often !. Attackers know this, and cracking tools apply exactly these transformations first.
The same applies to character substitution. Replacing e with 3, a with @, and s with $ feels clever but is one of the first rule sets any password cracker tries. P@ssw0rd! is not meaningfully stronger than password. NIST's current digital identity guidelines reflect this: they recommend dropping composition rules entirely and emphasising length instead.
Where randomness comes from matters
A password is only as unpredictable as the source that generated it. JavaScript's Math.random() is a pseudo-random number generator seeded from predictable state — sufficient for shuffling a playlist, wholly unsuitable for secrets, because output can be reconstructed by anyone who determines the seed.
Cryptographically secure generators draw from your operating system's entropy pool, gathered from genuinely unpredictable physical sources such as interrupt timings. In a browser that means crypto.getRandomValues(). It is worth checking which one a generator uses, because the difference is invisible in the output but total in effect.
A subtle bias worth knowing about
Even with a good random source, there is a classic implementation mistake: taking a random byte from 0 to 255 and applying modulo to map it onto a character set. If the set has 90 characters, bytes 0 to 89 map cleanly, then 90 to 179, then 180 to 255 — which covers only the first 76 characters again. Those early characters become slightly more likely.
The fix is rejection sampling: discard any byte that falls into the incomplete final block and draw again. It costs a negligible number of extra draws and makes the distribution genuinely uniform.
Practical guidance
- Use a password manager and let it generate long random strings you never have to read.
- For the handful of passwords you must type from memory, use a passphrase of four or five random words — genuinely random, not a phrase you chose.
- Never reuse a password across sites. Credential stuffing attacks rely entirely on reuse.
- Turn on two-factor authentication where it is offered; it protects you even when a password does leak.