Password Strength Checker: Evaluate and Improve Passwords

Why password strength still matters

Passwords remain the first gate for most accounts. Birthdays, phone numbers, and common words are still widespread. Breach reports (e.g. Verizon DBIR) keep showing weak or stolen credentials as a major intrusion path.

The password strength checker evaluates a candidate entirely in your browser: length and charset, common weak patterns, effective entropy, and an offline crack-time order of magnitude—plus concrete improvement tips. Understanding the dimensions beats staring at a color bar.

Risks of weak passwords

• Brute force: Short or numeric-only secrets fall quickly against offline hashes
• Dictionary / rules: Common words, keyboard walks, and leetspeak variants are in attacker lists
• Credential stuffing: One breach + reuse compromises every site with the same password
• Guessable personal data: Birthdays, name spellings, phone tails

Evaluation dimensions (aligned with this site’s tool)

1. Length

Length is the exponential term. Each extra character multiplies the search space by the charset size.

Takeaway: Length usually beats “sprinkle more exotic symbols.” Generate a long random string or passphrase with the password generator, then re-check with the strength tool.

2. Character-set diversity

Four classes: upper, lower, digits, symbols. Enabling more classes grows the charset and thus raw entropy. Obscure symbols you cannot remember are a trap—random length or a word phrase is steadier.

3. Weak-pattern detection (the tool penalizes these)

Even “long-looking” passwords can collapse to a tiny guess space:

Dictionary and rule attacks are not priced as full charset brute force. The tool reports effective entropy (raw entropy minus pattern penalties, with a cap) to reflect that.

4. Entropy and crack-time boundaries

Raw entropy ≈ length × log₂(charset size). This site then:

1. Applies pattern penalties (and floors common/leet hits to very low effective entropy)
2. Caps effective entropy at 128 bits—larger numbers add little for the offline-brute narrative
3. Estimates time in log space from effective entropy (half space / 10 billion guesses per second), avoiding charset^length overflow into Infinity/NaN

Rough bands (effective entropy):

• < 28 bits: offline-guessable soon
• 28–35 bits: medium
• 36–59 bits: stronger
• ≥ 60 bits: brute force usually impractical (reuse and phishing still matter)

Use cases

Before registering important accounts

Paste candidates into the local checker for bank, email, or cloud consoles. Built-in site meters vary; a trusted frontend-only tool is a useful second opinion.

Auditing old passwords

“Word + year” from years ago is still common. Drop candidates into the strength checker; if leet / year / keyboard flags appear, replace with the generator.

Team policy

Write policies that name a minimum length (e.g. ≥12), ban common lists and year suffixes, encourage passphrases, and store with bcrypt (or Argon2id)—not reversible encryption. Strength checking answers “how guessable is this string?”; bcrypt answers “how expensive is offline cracking of the store?”

Practical tips

1. Prefer length over symbol theater

# Weak: short and predictable
P@ssw0rd!2024

# Stronger: long unrelated words (or a random string)
correct-horse-battery-staple

Use the password generator (random / passphrase), then confirm effective entropy is not crushed by pattern penalties.

2. One password per site

Reuse fuels stuffing. A password manager remembers and fills; you guard the master secret plus 2FA.

3. Avoid personal data and year suffixes

Birthdays, phone numbers, and Name2024 live in rule dictionaries. The tool calls out trailing years explicitly.

4. Add a second factor

Strong passwords do not stop phishing pages. Enable TOTP or a hardware key on important accounts—see the TOTP tool.

5. Store with a slow hash

Client-side strength checks do not replace server-side bcrypt/Argon2. Generate → check → bcrypt hash is a complete local rehearsal chain.

How the password cluster fits together

Implementer's note

Scoring and pattern detection live in shared checkPasswordStrength: length/class bonuses; common list, leet, sequence, repeat, keyboard walk, and year-suffix penalties that also reduce effective entropy; effective entropy capped at 128 bits; crack time from 2^(entropy-1) / 1e10 in log form so Math.pow(charset, length) never overflows. The UI checklist and suggestion copy map that same result—no second rule engine in the component. The common list is a built-in hundred-ish sample, not a full Have I Been Pwned corpus—a miss does not mean “not breached.” Estimates assume offline GPU-class guess rates; online rate-limited login is far slower. Scores are heuristics, not cryptographic proofs.

FAQ

Why does P@ssw0rd score so poorly?

Leet normalization (@→a, 0→o, …) still yields a common root, and attack dictionaries include those variants. Prefer unrelated long strings or passphrases instead of symbol swaps.

Effective entropy vs “raw” entropy?

Raw entropy assumes uniform random draws from the charset. Keyboard walks and common words shrink the real guess space far below charset^length. The tool shows effective entropy after penalties (and possible capping).

Can the checker replace a password manager or bcrypt?

No. It only answers “how guessable is this string?” Managers solve reuse and memory; bcrypt/Argon2 solve storage-side brute-force cost. Treat the three as separate links.

Why is entropy capped for very long random passwords?

Past ~128 bits, offline brute force is no longer the interesting threat model; flashing 200+ bits misleads. After the cap, focus on uniqueness, manager storage, and slow hashing on the server.

A ToolVault engineering note. More free local-first tools at the homepage.