How long should a password be?

Updated April 28, 2026 · 10 min read · by Samuel Yoo

The honest answer to “how long should my password be” depends on three things: who’s attacking you, what they get access to, and how the server hashes it. The number changes by a factor of 1000× across realistic threat models. This is the working answer, with the math.

The variable that swamps everything else: server-side hashing

Before talking about length, the single most important thing to know: how the password is stored on the server completely changes the math. A 12-character random password is dramatically harder to crack when the server uses argon2id than when it uses plain SHA-256.

The same password is 5–9 orders of magnitude harder to crack against modern hashing than against plain SHA. When you read advice that “60-bit passwords are weak,” that’s usually the SHA-256 row. Against proper hashing, the same password is in “millions of years” territory.

You don’t control how the server hashes your password. So the practical question is: how long should your password be assuming the worst plausible server-side hashing? That’s the SHA-256 row.

Bits of entropy, plain English

Each “bit of entropy” doubles the number of guesses an attacker needs on average. A 60-bit password has 2^60 ≈ 10^18 possible values; an attacker has to try half of them on average.

Quick reference:

For passwords that live in a password manager (the only ones that should be character-random), aim for 80+ bits. For passwords you actually type (passphrases), 50+ bits is comfortable for most threat models because passphrase generation is easier to verify and harder to mistake for a low-entropy pattern.

The length math

Bits of entropy = log₂(charset_size) × length. So:

So a 14-character all-charsets random password ≈ 80 bits. That’s the recommended length for password-manager-stored passwords. Round up to 16 to give yourself a safety margin and meet most “must be 14+ characters” policies.

For passphrases: log₂(7,776) ≈ 12.92 bits per word with full diceware (EFF’s 7,776-word list). With our 256-word list it’s 8 bits per word. Either way, 5 words = 40+ bits which is enough for most uses, 6 words is comfortable, 7 is overkill for the threat model passphrases address (master passwords, laptop login).

The recommendations

For passwords you store in a password manager (most logins)

• 16 random characters, all charsets ≈ 105 bits. Past anything an attacker can throw at it.
• The exact number doesn’t matter much beyond ~14; entropy is exponential in length and the cost difference between 14 and 24 is negligible.
• Don’t worry about memorising; the password manager does that.

For passwords you have to type (master, laptop, encryption)

• 5- to 6-word passphrase with our 256-word list (40–48 bits).
• Or, equivalently, a 4-word EFF diceware passphrase (51 bits).
• Add a digit or symbol if a policy requires it; doesn’t change the security meaningfully.

For sensitive things you might type in front of someone

• 6-word passphrase — easy to type fast, harder to shoulder-surf than a typed character password where each tap is visible on screen.

For server / API tokens

• 32+ random characters, all charsets (≈ 210 bits). Treat like a key. Rotate when feasible. Don’t reuse across services.

For things you’ll burn after one use

• 12 characters. The threat model is “block opportunistic guessing during the brief window of validity,” not “withstand offline crack.”

Things that don’t matter as much as people think

• Capital letters at the start. If your password is Cyber123!, the capital is at position 1 — a crack tool tries that first. Capitalisation only adds entropy if it’s random, which it usually isn’t when humans choose.
• Symbols. They add ~1 bit per character vs all-letters, but only if random. ! at position N=length-1 is a crack-tool default.
• “Numbers and letters.” Mostly performative for password policies; see “common patterns” below.
• Forced periodic rotation. NIST removed this recommendation in 2017; it makes passwords worse (people pick easier-to-rotate ones, or write them down).

What does matter

• Length.
• Random (not human-chosen).
• Not reused across sites.
• Not present in any breach list (haveibeenpwned).
• Stored in a password manager so the above is feasible.

What kills your password

The crack tools (hashcat, John the Ripper) try patterns in this order:

1. Top-1000 most common passwords. Anything in this list cracks instantly.
2. Dictionary words + common modifications. Capital first letter, digit at end, ! at end. Password1! cracks in seconds.
3. Year suffixes. Cyber2024! is in pattern category 2 above.
4. Leet-speak substitutions. P@ssw0rd deletes to password; checked early.
5. Keyboard walks. qwerty, asdf, 1qaz2wsx.
6. Brute-force, increasing length. Only after the structured attempts above.

A truly random 12-character password with all charsets has 78 bits of entropy and goes nowhere on steps 1–5. It only falls on step 6, which takes years on a single GPU even at SHA-256 speed.

MyDog2024! has structured-attack entropy of about 25 bits — falls in step 2.

The TL;DR

• Password manager + 16+ random characters all charsets for everything that’s not your master password. ≈ 105 bits, 0 thinking.
• 5- or 6-word passphrase for your master password, laptop login, encryption keys. ≈ 40–48 bits, easy to type.
• Don’t reuse anything, even “weak” passwords.
• Check against breach lists at least once a year.
• The server-side hashing matters more than the length (which you don’t control), but going long means you’re safe even when the server is bad. Use the hash function selection guide if you’re on the server side and need to pick one.

Use the generator on the home page

It’s calibrated for these recommendations: default 20 characters all charsets, with a passphrase mode for the human-typed cases. The entropy meter shows the actual bits — not a vague “weak / medium / strong.”