This Password Passed Every Rule. A Strength Estimator Still Rated It Low

Password123! passed our composition rules but received a low pattern-based score. Our fictional examples show why password-checker outputs need their methods and context explained.

A checklist card and a separate gauge card, separated by a not-equal sign.

Quick answer

A password strength result depends on the method, its assumptions and the information it receives. Passing length and character rules does not show that a string lacks recognizable patterns. In our local comparison, Password123! passed all four policy checks but received zxcvbn’s 1/4 score. Treat scores as feedback, not a security guarantee, and never reuse our public examples as passwords.

Contents

Password123! met every rule in our test policy: at least 12 characters, an uppercase letter, a number and a special character. The zxcvbn estimator still assigned it a score of 1 out of 4. A separate library returned 0.521 on its own 0–1 scale.

We compared 24 deliberately public fictional strings with two local libraries. The point was to see what different measurements actually tell you, rather than rank commercial password-checking websites or measure how long an attacker would take to crack anything.

Rules and estimates ask different questions

Our composition policy checked four conditions: length of at least 12, one uppercase letter, one number and one special character. It reported which conditions were missing. That is a test of the specified rules.

zxcvbn looks for patterns such as dictionary words, repeats and sequences, then estimates guessing difficulty. We used the Python zxcvbn 4.4.28 package, which is a port of Dropbox’s estimator. The original zxcvbn documentation describes its pattern-based approach and optional user-specific inputs.

The second estimator was password-strength 0.0.3.post2. We recorded its native strength and entropy estimates, along with the policy results from that package. Its 0–1 output is a different measurement from zxcvbn’s 0–4 score. Dividing one scale or multiplying the other would not make them equivalent.

What our fictional examples returned

We used repetition, keyboard and dictionary patterns, familiar mixed-case strings, phrases and seeded generated strings. Every example is public research data, not a suggested credential.

Public fictional exampleComposition policyzxcvbn nativeOther native 0–1
passwordFail0/40.250
Password123!Pass1/40.521
ElegantMatter2026!Pass4/40.768
correct horse battery stapleFail4/40.920

Password123! illustrates a recognizable pattern that still meets the composition rules. The phrase example illustrates another mismatch: it failed some of our specified character rules while receiving the highest zxcvbn category. Neither result establishes that the public phrase is a suitable password to use now.

The scores alone also leave out reuse. A string may receive a high estimate while already being known to someone or reused across accounts. Our local test did not check breach databases, account history or real users’ passwords.

Adding context changed a result

We ran a separate zxcvbn comparison with four user-input strings: Elegant, Matter, October and 2026. The rest of the library and scoring method stayed the same.

ElegantMatter2026! moved from zxcvbn score 4 to score 3. Its reported guessing estimate changed from 2,025,224,800,000 to 1,600,000,000. October2026! kept score 2, but its guessing estimate also changed. The complete 24-example context results are retained, including those that did not change.

These are estimator outputs under two input conditions. We did not perform that many guesses or time a cracking operation. The comparison shows that information supplied to a checker can affect its prediction even when the tested string is identical.

Why predicted crack time needs assumptions

A tool may turn an estimated number of guesses into a time by assuming a guessing rate. A rate appropriate to an online login with restrictions differs from a hypothetical offline attack. The estimator’s underlying pattern model and dictionaries matter too.

We did not measure online throttling, password hashing, attack hardware or access to an account. Our data therefore supports a comparison of library outputs, without supporting a measured crack-time claim or a winner for real-world protection.

Two websites can also use the same underlying estimator. Comparing their displays would not necessarily compare two independent algorithms. Our test used two distinct local libraries; it did not audit which methods any named website currently uses.

How to use a checker sensibly

Use feedback to notice predictable patterns and avoid confusing a completed checklist with a guarantee. Keep account-specific context and the limits of the displayed result in mind. Do not paste a real password into an unfamiliar checking service merely to compare scores.

For actual accounts, follow the service’s requirements and use unique credentials generated and stored through a trusted password manager. Current NIST authentication guidance distinguishes password length and blocklist checks from mandatory character-composition rules, and supports password managers. Those recommendations are external guidance; our experiment did not measure the security of a manager or authentication service.

Our guide to how passkeys change authentication explains the differences between passwords and passkeys, including device loss and recovery.

Method and reproducibility

The experiment was run on 13 Oct 2026 with Python 3.12.14, zxcvbn 4.4.28 and password-strength 0.0.3.post2. The 24-string corpus and generation seed were fixed, the full baseline comparison was repeated, and the context follow-up was run twice with matching outputs. Native scales, rule failures and pattern labels are preserved in the results.

The downloadable study package uses only deliberately public fictional strings and local scripts. It contains no personal passwords, account identifiers or breach material.

Download the study files and results (ZIP).

Original fixtures, scripts and study results are available under CC0 1.0; third-party software retains its own licenses.