Password Checker Developer Tool

How entropy is estimated

This tool estimates entropy as length × log2(pool size), where the pool size is the sum of the character classes actually present in the password (26 for lowercase, 26 for uppercase, 10 for digits, and roughly 33 for common symbols). This is a rough but useful proxy: it assumes every character was chosen independently and uniformly at random from that pool, which is exactly true for a generated password but only approximately true for a human-chosen one. A password like Tr0ub4dor&3 scores well on this formula because of its length and character variety, even though it's derived from a recognisable word with predictable substitutions — a real attacker's cracking dictionary would find it far faster than the raw entropy number suggests. That's why this tool layers pattern checks (common passwords, sequences, repeated runs) on top of the entropy estimate rather than relying on entropy alone.

What the crack-time estimate assumes

The estimated time to crack converts entropy bits into a guess count (2^entropy) and divides by an assumed guessing rate — this tool uses 10 billion guesses per second, representative of a fast offline attack against a stolen, unsalted hash using modern GPU hardware. Real attacks vary enormously: an online login form that rate-limits attempts might allow only a handful of guesses per second, while an offline attack against a password hashed with a slow, memory-hard algorithm like bcrypt or Argon2 could be millions of times slower than this estimate. Treat the number as a relative indicator of strength rather than a literal countdown — it's most useful for comparing two candidate passwords, not for predicting exactly how long any specific account is safe.

k-anonymity and the Have I Been Pwned check

Checking a password against a breach database naively would mean sending the password itself to a third-party server — something this tool deliberately avoids. Instead it hashes the password locally with SHA-1 and sends only the first five characters of that hash to the Pwned Passwords range API. The API responds with every hash suffix on record that shares that five-character prefix, typically several hundred to a few thousand candidates, and the actual match is found locally by comparing suffixes in the browser. This is k-anonymity in practice: the server learns only that a hash starting with those five characters was queried, not which one, so it cannot determine your actual password even in principle. SHA-1 is used here purely as a lookup key against a known breach corpus, not as a security mechanism — it has nothing to do with how the password itself should be stored.

Why password reuse is the bigger risk

A strong, unique password can still be compromised if the site storing it is breached and the password is reused elsewhere. Credential-stuffing attacks take exactly this shape: attackers replay email/password pairs leaked from one breach against many other sites, banking on the fact that a large share of people reuse passwords. This is why the breach check here matters as much as the strength meter — a password can have excellent entropy and still be dangerous if it has appeared in a public breach corpus, because it's now a known credential-stuffing candidate regardless of how "random" it looks.

Current guidance (NIST SP 800-63B)

NIST's modern digital identity guidelines de-emphasise the composition rules of older policies. The current recommendations favour length over enforced complexity, screening new passwords against lists of known breached and commonly used passwords (rather than requiring specific character types), and dropping mandatory periodic expiry in favour of changing a password only when there's reason to believe it's been compromised. This tool's checklist reflects that shift: length and breach status carry more weight than ticking every character-class box.