How to pick a strong password (and the four rules everyone gets wrong)

Most password advice is wrong, or at least out of date. The 2003 NIST guidelines (uppercase + lowercase + number + symbol, rotate every 90 days) made sense given the threat model of the time and the cost of authentication primitives. Both have changed. Modern password security comes down to four rules, in priority order.

Rule 1: Length beats complexity

Entropy — the actual measure of how hard a password is to brute-force — is length × log₂(charset). Three combinations producing roughly 80 bits:

• 16 random lowercase letters: 16 × log₂(26) ≈ 75 bits
• 12 random chars from a 70-symbol alphabet: 12 × log₂(70) ≈ 74 bits
• 6 random words from a 7,776-word list: 6 × log₂(7776) ≈ 77 bits

At 80 bits, brute-forcing at one trillion attempts per second takes ~38,000 years. That’s the floor for “not worth trying.” To get there: extend the length, not the character classes. kjY8 has 23 bits; kjY8kjY8kjY8 at 12 chars has 69; same input complexity, vastly stronger.

Rule 2: Unique per account

The single biggest risk to your accounts is credential stuffing — attackers taking usernames and password hashes from a breach (a B-list site you used in 2015), cracking them offline, then trying the result on every major service. If you reuse the same password across services, one breach compromises all of them.

Unique-per-account passwords make this attack class irrelevant. The only practical way to maintain dozens of unique strong passwords is a password manager (1Password, Bitwarden, Apple Keychain, etc.). Use one.

Rule 3: Cryptographically random, not human-chosen

Human-chosen passwords cluster. We pick birth years, keyboard patterns, dictionary words, anagrams, names. Even when told to be random, humans aren’t.

Cryptographic randomness avoids this entirely. Our password generator uses crypto.getRandomValues with rejection sampling to produce uniformly random passwords from any charset. Generated 20-character outputs give ~131 bits of entropy in the full alphabet — past the useful upper bound for any threat model not involving quantum computers.

Rule 4: Two-factor where supported

Two-factor authentication (a code from your phone, a hardware key, a passkey) defeats password compromise even when the password itself is weak or reused. Modern phishing attacks have become good enough at capturing one-time codes that the bar has risen — but a strong password plus any 2FA is still vastly safer than a strong password alone.

Use hardware keys (FIDO2 / WebAuthn) where possible, TOTP apps (Authy, 1Password, Aegis) where hardware keys aren’t supported, SMS only as a last resort. SMS 2FA is better than no 2FA but worse than the alternatives — SIM-swap attacks are real.

The xkcd passphrase question

Randall Munroe’s xkcd 936popularised the four-random-words passphrase. It’s a good idea with two caveats:

• Words must be drawn from a large list.A 7,776-word list (the EFF’s Diceware) gives ~13 bits per word. A 2,000-word list gives ~11. Common English vocabulary (10,000 words an educated adult might pick) gives even less because humans don’t pick uniformly.
• The whole passphrase must be random. “Correct horse battery staple” itself is now in every password-cracking dictionary. The example was good when it was an example.

The four most common failure modes

1. Reused across sites. One breach takes them all.
2. Pattern-based. “[Site]2024!” — automated tools catch these immediately.
3. Personal info. Birthdays, pet names, schools — all available on social media or in databases.
4. Too short. Below ~50 bits of entropy is brute-forceable in a reasonable budget.

The pragmatic strategy

For every account:

1. Use our password generator at 20+ characters with all classes enabled.
2. Save it in your password manager.
3. Enable hardware-key or TOTP 2FA on accounts that support it.
4. Never reuse a password between accounts.
5. For the few passwords you must remember (your password manager’s master, your phone PIN), use a 6+ word random passphrase.

Don’t change passwords on a schedule. Change them when a breach is reported on a site you use, or when you have any other concrete reason to suspect compromise.