How to measure password strength

Password strength meters often lie. “Tr0ub4dor&3” scores “strong” on most meters but takes hours to crack; “correct horse battery staple” scores weak but takes centuries. Strength is about entropy and resistance to known attacks, not about symbol mixing. This guide covers what password strength actually measures, the meters that get it right (zxcvbn) vs the ones that get it wrong (rule-based), how length beats complexity, why breach-checked matters more than “strong,” and practical guidance on building passwords that resist real-world attack patterns.

What strength meters try to measure

Password strength = how long it takes an attacker to crack it with current hardware and methods. Measured in guesses (before a crack is likely) or equivalent bits of entropy.

Three common methods, in decreasing order of badness:

Rule-based: “must have uppercase, digit, symbol.” Scores Password1! as strong. Terrible. This is what most corporate policies use.

Shannon entropy on character classes: 8-char password with 72 symbols ≈ 49 bits. Ignores dictionary words. Slightly better but still fooled by common patterns.

Attack-simulation (zxcvbn): models actual cracking — dictionary attacks, leet substitutions, keyboard patterns, dates, common names. Scores log₁₀(guesses) 0-4. Realistic and widely used.

The rule-based meter problem

The rules “uppercase + digit + symbol + 8 chars” came from a 2003 NIST doc. NIST retracted that guidance in 2017, but corporate IT kept it.

The rules push users toward predictable patterns: capitalize first letter (Password), append a digit (Password1), add a symbol (Password1!). Attackers know. They try those permutations first.

Modern NIST SP 800-63B guidance: length over complexity. Allow all ASCII and Unicode. Don’t force periodic rotation. Check against breach lists. Check against dictionaries.

Length beats complexity

A 12-char password from a 26-letter alphabet has 26¹² ≈ 9.5 × 10¹⁶ combinations. A 16-char password from a 26-letter alphabet has 26¹⁶ ≈ 4.3 × 10²². Four extra lowercase characters add more entropy than adding uppercase and digits.

Practical implication: passphrases of 4-6 random words beat “strong” 8-char passwords both in security and memorability.

Example passphrases: “correct horse battery staple” (~44 bits); “marine peach rocket helm panda” (~55 bits). Both easier to remember than “X#9qLmp4” and vastly stronger.

zxcvbn — the right meter

Dropbox’s zxcvbn simulates cracker logic:

Checks 30,000+ most common passwords.

Checks dictionary words (including inverted, password → drowssap).

Leet substitutions: p@ssw0rd is scored like password.

Keyboard patterns: qwerty, asdfgh, 1qaz2wsx.

Repeats/sequences: aaaa, 1234, abcde.

Dates: 1987, 01011990.

Outputs a score 0-4 and an estimate of guesses needed. 4 ≈ “safe from offline slow-hash crack with 10 years effort”. 3 ≈ “safe from offline fast-hash”. 2 ≈ “safe from online throttled”. 0-1 ≈ crack within minutes.

Breach exposure > theoretical strength

The strongest-looking password loses all value if it’s in a breach. Hg7$sKq3Mpx9 looks strong but if it’s in a leaked dump, attackers try it first in credential stuffing.

Strength check + breach check together:

Strength check: theoretical difficulty for an attacker who doesn’t have the password yet.

Breach check: whether the password is already known to attackers.

Use both. Breach-clean + zxcvbn 3+ is a reasonable bar.

Attack models matter

Strength depends on how an attacker can try passwords:

Online throttled: login form with rate limits. ~10 guesses/second max. Even weak passwords survive short attacks.

Online unthrottled: login form without limits. 100-1000 guesses/second. Weak passwords fall fast.

Offline fast hash (MD5/SHA-1): password hash was leaked. Billion guesses/second on GPU. 8-char random passwords fall in hours.

Offline slow hash (bcrypt/argon2): password hash was leaked but the hash algorithm is deliberately slow. Thousands of guesses/second. 12+ char random passwords hold.

Design for the worst case: offline fast hash. If your password would crack there, it’s too weak.

What strength doesn’t protect against

Phishing: a strong password given to a fake site is a weak password. No strength helps here — MFA does.

Keyloggers: strength irrelevant if the attacker captures keystrokes.

Password manager breach: your vault contains all strong passwords. If the vault is cracked, every password leaks. Use a strong master + MFA.

Session stealing: cookies grant access post-login. Strength doesn’t help.

Strong passwords matter. They’re not the whole story.

Good passwords by use case

Master password for a password manager: 5+ random words, memorable. Write it down somewhere physically safe. This is the one password you cannot forget.

Per-service passwords: generated by your password manager, 16+ random characters. You don’t memorize these.

Offline / accounts without a manager: 4-word passphrase with a digit and symbol inserted — still memorable, still strong.

Common mistakes

Trusting rule-based meters. “Strong” in the meter often means “crackable in under an hour”.

Optimizing for theoretical entropy while reusing. Even the strongest password is weak if shared across services.

Using personal info. Pet names, birthdays, addresses all in public data. Crackers know.

Rotating passwords on a schedule. Without cause, rotation pushes users toward predictable variants. NIST now recommends rotating only after compromise.

Ignoring length. An 8-char “strong” password is weaker than a 16-char all-lowercase phrase.

Checking strength but not breach exposure. “Strong” in a breach is still compromised.

Run the numbers

Measure the real strength of your password with the password strength checker. Pair with the password breach checker for exposure, and the password generator to create unique strong replacements.