Password Strength Explained: Entropy, Crack Times, and Why "Password1!" Is Weak

Most password strength meters lie. Type Password1! into a typical registration form and watch it turn green. It has uppercase, lowercase, a digit, and a symbol — all four boxes ticked. Yet every serious password cracker checks it in the first few seconds. It sits in every leaked-password dictionary, and the pattern Capitalword + digit + punctuation is one of the first mutation rules applied to wordlist attacks. Use the Password Strength Checker to test your own passwords as you read through this article.

Why Length Matters More Than Complexity

Password strength is fundamentally about how many guesses an attacker needs to try before finding your password. That number is determined by entropy — measured in bits. Entropy is calculated as:

entropy = log2(charset_size) × length

Where charset_size is the number of distinct characters the attacker must consider for each position, and length is the number of characters. Every additional bit of entropy doubles the search space. Adding one character to a random password multiplies the attack cost by the charset size. Adding a requirement for one more character class (say, a symbol) only modestly increases entropy if the attacker already assumes symbols are possible.

Consider two passwords: correct#1 (9 characters, mixed charset) versus rjwmpltkszfd (12 random lowercase). The 12-character lowercase password has roughly 56 bits of entropy (log2(26) × 12 ≈ 56.4). The shorter mixed password, despite containing four character classes, has around 42 bits if chosen by a human following a predictable pattern — and even less if it matches a dictionary word with substitutions. Length wins.

Entropy Table: Charset Size × Length

The table below shows how many bits of entropy a randomly chosen password of a given length and charset provides, and a rough crack-time estimate against a fast offline attacker (100 billion hashes per second on a GPU cluster — typical for SHA-256).

These estimates assume the attacker does not know your password is random. For human-chosen passwords, real crack times are far shorter because attackers exploit patterns — dictionary words, common substitutions, keyboard walks, and date patterns.

Hardware Classes and Attacker Scenarios

Not all attacks are equal. The crack time depends entirely on what the attacker has access to:

The key insight: the algorithm the site uses determines how much your password length matters in a breach scenario. A 10-character password hashed with bcrypt is substantially harder to crack than a 16-character password hashed with MD5. Sites using bcrypt or Argon2 are doing the right thing — but you cannot know which algorithm a site uses until it gets breached. Err on the side of length.

Why zxcvbn Is Smarter Than "Has Uppercase + Digit + Symbol"

The library zxcvbn (developed by Dropbox, now widely used) does not check character classes. It estimates how many guesses an attacker would need to crack the password by modeling the same techniques real crackers use:

• Dictionary matching: checks against common passwords, names, English words, and TV/film references (over 30,000 entries)
• L33t substitution: recognizes that p@ssw0rd is just password with predictable character swaps
• Keyboard patterns: detects walks like qwerty, zxcvbn, 1qaz2wsx
• Date patterns: recognizes 19871023, 10/23/1987, 19870523 as low-entropy date sequences
• Repeats and sequences: flags aaaaaa, 123456, abcdef
• Structural patterns: detects combinations like word + year + symbol that are ubiquitous in human-chosen passwords

zxcvbn returns an estimated number of guesses alongside the score. A password that scores poorly under zxcvbn is one that falls early in a realistic cracking session.

The zxcvbn Score 0–4 and What Beats Each

Score 3 is the practical minimum for accounts that matter. Score 4 is appropriate for master passwords, SSH keys, and anything that unlocks other credentials. Use the Password Generator to generate passwords that reliably reach score 4.

Why Forced Complexity Rules Backfire

When a site mandates one uppercase, one digit, one symbol, and a minimum of eight characters, users converge on the same patterns. The password becomes predictable in a different way: Password1!, Welcome2024!, Summer2024#. These satisfy every complexity rule and appear in every serious cracking wordlist under "mangled dictionary."

Periodic rotation requirements make things worse. Users who must change their password every 90 days adopt patterns like Password2024Q1! → Password2024Q2!. An attacker who cracks one rotation can trivially predict the next. NIST SP 800-63B (the current US federal standard) explicitly recommends against mandatory periodic rotation, and instead recommends checking new passwords against breach lists.

The most effective policy is simple: minimum 12 characters, no complexity requirements, breach-list checking at registration and password change.

Breach-List Checking: Have I Been Pwned

Troy Hunt's Have I Been Pwned (HIBP) maintains a database of over 10 billion passwords from real data breaches. The Pwned Passwords API lets you check whether a password appears in the database without ever sending the password to a server, using a k-anonymity model:

1. Hash the password with SHA-1.
2. Send only the first 5 characters of the hex hash to the API: GET https://api.pwnedpasswords.com/range/5BAA6
3. The API returns all hash suffixes that begin with those 5 characters (typically 500–900 results).
4. Compare the rest of your hash locally. If it matches, the password is compromised.

The server never sees your full hash, let alone your password. Integrating this check at registration is a concrete security improvement. The Password Strength Checker performs this check client-side.

Real-World Examples

The XKCD 936 examples are instructive. Tr0ub4dor&3 looks strong to naive meters but zxcvbn correctly gives it a 2 because the underlying word is dictionary-matched and the transformations are predictable. correcthorsebatterystaple is genuinely better — but only because it uses four words, not because they are common.

Implementation Pitfalls

Building a password strength checker into your application introduces its own failure modes:

• Leaking the password in query parameters: Never pass a password as a URL query parameter to a strength-checking endpoint. Query parameters appear in server logs, browser history, and HTTP referer headers.
• Client-only checks without breach lookup: A client-side entropy score tells you nothing about whether the password is already in a breach database. Combine entropy scoring with the HIBP k-anonymity check.
• Showing the password mid-type: A visible strength meter that evaluates on each keystroke is useful — but make sure the password field itself defaults to masked input. Some implementations accidentally echo the value in the UI or console.
• Over-relying on the score without a minimum threshold: A score of 2 is not acceptable for production authentication. Set a hard minimum of score 3 (or equivalent entropy threshold) before allowing account creation.
• Not re-checking at login: If a user set their password before you added breach-list checking, they may still be using a compromised password. Consider prompting a reset on next login if the stored hash appears in the HIBP database.

Password strength is ultimately about search-space size relative to attacker capability. Length adds entropy multiplicatively. Complexity adds entropy only marginally. Breach-list checking catches passwords that are theoretically strong but practically compromised. Use the Password Strength Checker to evaluate your current passwords, and the Password Generator to create ones that are genuinely hard to crack.