🔒 🔒 Password Strength Checker: How Password Strength Is Measured

Password strength checkers vary wildly in quality. Some check only length and character types, giving P@ssw0rd a high score despite it being one of the most common passwords in breach databases. The best modern checkers — like Dropbox's open-source zxcvbn — estimate real-world crackability by simulating how actual attackers approach password guessing. Understanding how these tools work helps you create passwords that are genuinely resistant to attack.

What Naive Password Checkers Miss

Many password strength meters score based only on:

• Length (number of characters)
• Presence of uppercase letters
• Presence of lowercase letters
• Presence of numbers
• Presence of symbols

By these rules, "P@ssw0rd1!" scores as "strong" — it's 10 characters, uses upper, lower, number, and symbol. In reality, it appears in virtually every password attack dictionary and would be cracked almost instantly.

The problem: naive checkers don't account for predictable patterns.

The zxcvbn Algorithm: Realistic Strength Estimation

Dropbox open-sourced zxcvbn in 2012 as a more realistic password strength estimator. It simulates how attackers actually crack passwords by checking a password against multiple attack vectors:

1. Dictionary attacks: Checks the password and its variations against 30,000+ common passwords (including the most common breach passwords), English words, names, dates, and popular culture references
2. Keyboard pattern detection: Recognizes patterns like "qwerty," "12345," "zxcvbn," and keyboard walks across any keyboard layout
3. L33t substitutions: Automatically evaluates common substitutions like a→@, e→3, i→1, o→0, s→$ against its dictionaries
4. Repeat/sequence detection: Identifies repeated characters ("aaaa"), repeated patterns, and alphabetical/numeric sequences
5. Date patterns: Recognizes dates in various formats (1990, 19901231, 12/31/1990)

The result is a crack time estimate (e.g., "3 hours online" or "centuries offline") rather than just a score, which is far more meaningful.

Understanding Crack Time Estimates

Password cracking difficulty depends on whether the attack is:

• Online attack (throttled): An attacker trying passwords through a website login page. Typically rate-limited to 10–100 guesses per second by the server. Even a moderately weak password might take days.
• Online attack (unthrottled): A system without rate limiting. 1,000 guesses/second is realistic.
• Offline attack (slow hash): An attacker who has obtained hashed passwords from a database breach and is cracking them locally. Using bcrypt, Argon2: ~10,000 guesses/second per GPU.
• Offline attack (fast hash): Same, but with MD5 or SHA-1 hashes. Modern GPUs: billions of guesses per second.

This is why the hash algorithm used to store passwords matters enormously. A password that would take centuries against bcrypt might fall in minutes against an MD5 hash.

What Actually Makes Passwords Strong

Length is the dominant factor

Increasing password length has an exponential effect on crack time. Adding one character from a 95-character set multiplies crack time by 95. Adding two characters multiplies by 9,025.

Unpredictability beats complexity

A password that passes all character type requirements but follows a predictable pattern is weak. "Summer2024!" looks complex but an attacker will try "Season + Year + Symbol" patterns early in their attack. "xK$m9vL#wP2q" is genuinely harder despite similar apparent complexity.

Uniqueness across sites

The second most important factor after length is using a different password for every account. Password reuse means one breach exposes all your accounts — credential stuffing attacks try stolen username/password pairs across hundreds of services automatically.

Common Password Weaknesses

The "Have I Been Pwned" Integration

NIST's 2024 password guidelines recommend checking new passwords against known breached password databases. The Have I Been Pwned (HIBP) Passwords API allows checking if a password has appeared in any known data breach — without ever sending the actual password to the server (using a k-Anonymity model where only the first 5 characters of the SHA-1 hash are sent).

Passwords that have appeared in breaches should always be rejected, regardless of how strong they appear by other metrics — they are already in attacker dictionaries.