Password Strength Checker

What "Password Strength" Actually Measures

A password's strength is a single concept: how many guesses must an attacker make, on average, before they hit yours? That number is determined by entropy, measured in bits. A password with N bits of entropy requires about 2^N−1 guesses to crack via brute force. 60 bits is the conventional floor for anything you care about. 128 bits is what password managers generate by default and is unreachable for any current attacker.

This tool calculates entropy from two things: the character pool the password draws from (26 lowercase = ~4.7 bits per char, 94 printable ASCII = ~6.55 bits per char) and the length. Naive entropy = pool_size_in_bits × length. Then it applies penalties for patterns that lower real-world strength: dictionary words, repeated characters, sequential runs, common substitutions (e → 3, a → @), and known leaked passwords. The number you see is the effective entropy after those deductions.

Why "Tr0ub4dor&3" Is Not Strong

The famous XKCD comic Password Strength made the point in one panel: Tr0ub4dor&3 looks like a strong password under traditional composition rules (mixed case, digits, symbol, 11 characters), but its real entropy is roughly 28 bits. Why? Because attackers don't try aaaaa…, aaaab…, aaaac… — they run rule-based dictionary attacks. Hashcat will try troubador with a few hundred mutation rules (capitalize first letter, replace o → 0, append a digit and symbol) in microseconds, and finds Tr0ub4dor&3 on the first thousand candidates.

The same comic showed correct horse battery staple — four random common words. Naive entropy of a 28-character string is huge, but real entropy depends on the word list size, not the character count. Four random words from a 7,776-word list (EFF Diceware) gives 51.6 bits — significantly stronger than Tr0ub4dor&3 and dramatically easier to type and remember. This tool gives partial credit for passphrase patterns when it detects them.

How Crack Time Is Estimated

Once we know entropy, crack time = 2^entropy ÷ guesses-per-second. The tool shows three scenarios:

• Online attack — 10⁶ guesses/sec. An attacker hammering a login form. In practice rate-limiting usually drops this to under 100/sec, so this is a worst-case where rate-limiting is broken.
• Offline GPU — 10⁹ guesses/sec. An attacker who stole a password hash database and runs hashcat on a single high-end GPU against a fast hash like MD5, SHA-1, or unsalted SHA-256.
• Offline cluster — 10¹² guesses/sec. An attacker with a GPU cluster (cloud rented for cents per hour). This is plausible for any well-funded threat actor in 2026.

One critical caveat: for hashes properly protected with bcrypt (cost ≥ 10), scrypt, or Argon2 (modern parameters), divide the offline-attack number by roughly 10⁶ — these algorithms deliberately make each guess thousands of times slower. A password that takes 1 second to crack against unsalted SHA-256 takes ~12 days against bcrypt at cost 10. Always use a slow hash for password storage; the password's own strength is your second line of defense, not your first.

What Makes a Password Weak

The tool deducts entropy when it detects any of these:

• Dictionary words — A 7-letter word from a 14-million-word list contributes ~24 bits, not 4.7 × 7 = 33 bits.
• Common substitutions — Replacing letters with look-alikes (a → @, e → 3, o → 0, i → 1, s → 5) is the very first rule attackers try. A "leetspeak" password gets the same score as the underlying word.
• Sequential characters — abcdef, 123456, qwerty contribute almost no entropy. Keyboard walks (asdfghjkl, 1qaz2wsx) are in every attack ruleset.
• Repetition — aaaaaa is one character of effective entropy, not six. Same for abcabcabc.
• Year suffix — Appending 2024, !, or 123 adds maybe 4 bits. Attackers test these suffixes by default.
• Personal info — Names, birth dates, partner names, pet names, and city names appear in targeted attacks. The tool can't detect these, but they should never appear in a password.

How to Pick a Strong Password

The right strategy depends on whether you need to remember it:

• For most accounts — Use a password manager (1Password, Bitwarden, KeePass) and let it generate a 16+ character random string. You never type or read these passwords; the manager fills them in. This gets you 95+ bits of entropy effortlessly.
• For master passwords (vault, full-disk encryption, key files) — Use a 5–6 word passphrase from EFF Diceware, with random words generated by physical dice or a CSPRNG. Five words ≈ 64 bits, six ≈ 77 bits. Don't choose the words yourself — your brain is a terrible random source.
• For high-stakes single use (recovery codes, key escrow) — 256 bits of entropy. Generate with a CSPRNG using our Random String Generator and store in a paper backup or hardware token.

Whatever you do: do not reuse passwords across services. The strongest password in the world is worthless if it's also your password on a forum that gets breached and dumped. Reuse turns one compromise into N compromises. A password manager makes per-site passwords trivially feasible.

NIST 800-63B and the Death of "Complexity Rules"

Older policies — "at least 8 characters, one uppercase, one digit, one special character, change every 90 days" — were written when offline attacks were rare and dictionary attacks were primitive. They produce remarkably predictable patterns: Password1, Spring2024!, Welcome@123. Attackers know this, and these patterns are the first things checked. NIST's 2017 update (800-63B) and CISA's current guidance both recommend:

• Minimum length 8 (preferably 12+), no maximum
• Allow all printable ASCII, including spaces — enables passphrases
• Screen against known-breached password lists (Have I Been Pwned API)
• Drop arbitrary composition rules (mandatory uppercase/symbol)
• Drop forced periodic rotation — only rotate after evidence of compromise
• Require multi-factor authentication on anything important

If your company is still enforcing 90-day rotation on a 10-character password with a complexity policy, the policy is the weakness, not the user.