Password Entropy: Why "Tr0ub4dor&3" Loses to Four Random Words

Entropy is about the process, not the string

A password’s strength is the number of equally-likely alternatives the generation process could have produced, measured in bits: entropy = length × log₂(alphabet size) — *if and only if* every character was chosen uniformly at random. A human "randomly" typing produces nothing close to uniform: dictionary words, keyboard walks and birthdays collapse the real search space by orders of magnitude. Attackers do not brute-force character-by-character; they brute-force *the way people think*.

This is why Tr0ub4dor&3 is weak despite its symbols: it is one dictionary word with predictable substitutions (0 for o, 4 for a) plus a trailing symbol-digit — a pattern every cracking tool tries early. Four genuinely random common words (correct horse battery staple style) draw from ~2⁷⁷ possibilities and beat it by thirty-plus bits.

What crack-time estimates really assume

A "3 centuries to crack" estimate assumes a specific attacker: offline attack against a leaked hash, at some guesses-per-second rate. The rate varies by a factor of a million depending on how the site hashed your password — GPU rigs try hundreds of billions of MD5 guesses per second but only tens of thousands against a properly tuned bcrypt or Argon2. You cannot control the site’s hashing; you can control being far enough into the search space that even the fast case is hopeless. Aim for 80+ bits; 100+ for anything guarding money or email.

Passkeys and MFA: the password is no longer alone

Password strength matters most where a password is the *only* factor. Two developments change that calculus. Multi-factor authentication — an authenticator app code or, far better, a hardware key — means a cracked or phished password alone does not open the account; SMS codes are the weakest MFA (SIM-swapping is routine) but still beat nothing. Passkeys go further: a public-key credential bound to your device and the site’s real domain, unlocked by biometrics or PIN. There is no shared secret to leak, nothing to type, and phishing sites cannot use them because the key refuses to sign for the wrong origin. Where a service offers passkeys, enable them; keep a strong password as the fallback and turn on MFA for it.

Storing passwords if you build the login

If you are on the other side — writing the system that *receives* passwords — the rules are short and non-negotiable. Never store a password; store a slow, salted hash from a purpose-built algorithm: Argon2id (preferred), scrypt, or bcrypt with a work factor tuned so a hash takes ~100–250 ms on your hardware. Never use MD5, SHA-1 or plain SHA-256 for passwords — they are fast by design, which is exactly what an attacker wants. Compare hashes in constant time, rate-limit and lock out on repeated failures, and check new passwords against known-breached lists (the k-anonymity API of Have I Been Pwned lets you do this without sending the password). Length limits should be generous (64+ characters) and composition rules minimal — NIST’s current guidance is length and breach-checking over forced symbols and rotation.

Generated strings vs passphrases: both, in different places

• Random 20+ character strings for everything stored in a password manager — maximum entropy per character, and you never type them.
• Diceware-style passphrases (5+ random words) for the few secrets you must type or memorize: the manager’s master password, disk encryption, your OS login.
• Never reuse either. Credential-stuffing from old breaches compromises more accounts than cracking does; uniqueness beats strength.
• Length beats complexity rules: a 16-character lowercase string out-entropies an 8-character string using all four character classes.