How This Meter Works
This tool demonstrates one approach to password strength estimation. Your assignment is to build your own version — the explanation below shows what this implementation considers.
1. Entropy Estimation
Entropy measures the unpredictability of a password. It's calculated as log2(pool_size ^ length) where pool size depends on which character classes are used: 26 for lowercase, 26 for uppercase, 10 for digits, 33 for common symbols, and more for extended Unicode. A password using all classes has a pool of 95+, meaning each character contributes ~6.5 bits of entropy.
2. Pattern Detection
Raw entropy overestimates strength if the password contains predictable patterns. This meter checks for: sequential characters (abc, 123), keyboard walks (qwerty, asdf), repeated characters (aaa, 111), common substitutions (@ for a, 3 for e, 0 for o), date patterns, and whether the password appears in a list of 1,000 common passwords embedded in this page.
3. Crack Time Estimation
Using the effective entropy (after pattern penalties), we estimate crack time assuming an offline attack at 10 billion guesses per second — representative of a modern GPU cluster running against unsalted hashes. Salted/iterated hashes (bcrypt, Argon2) would dramatically increase this time.
4. HaveIBeenPwned API (k-Anonymity Model)
This version integrates the HIBP Passwords API to check if a password has appeared in real data breaches. The API uses a k-anonymity model: we compute the SHA-1 hash of the password locally, send only the first 5 hex characters (the "prefix") to the API, and receive back all hash suffixes that match that prefix along with their breach counts. We then check locally whether our full hash appears in the returned list. This means your full password (or its full hash) never leaves your browser.
The flow is: password → SHA-1 hash → send first 5 chars → API returns matching suffixes → check locally for full match → display breach count.
A connection status indicator shows whether the API is reachable. If the API is unavailable (no internet, API down, or CORS issues), the tool still functions using all offline checks — only the breach count feature is disabled.
5. NIST SP 800-63B Considerations
NIST's current guidance emphasizes length over complexity rules. They recommend: minimum 8 characters (preferably 15+), checking against breach/common password lists, allowing all printable ASCII and Unicode, and NOT requiring periodic rotation or specific character-class rules. This meter reflects those priorities by weighting length heavily and not penalizing the absence of special characters if length is sufficient.
The HIBP integration directly satisfies NIST's requirement that verifiers "SHALL compare the prospective [password] against a list that contains values known to be commonly-used, expected, or compromised" (SP 800-63B Section 5.1.1.2).