Stop blocking only 'too short': password strength and breach checking for vibe projects

A counterintuitive fact first: a password that passes the rules may already be leaked

Most products' password rules look like this: at least 8 characters, with uppercase and lowercase letters, digits, and a special character. By those rules, "Password123!" is a perfect password: long enough, all character classes present, no obvious repetition. It is also a regular in leaked-password databases — thousands of people have used it, and the first thing an attacker tries after obtaining a breach dump is exactly that. The rules blocked "123456" but waved through a password that "looks complex but everyone uses." That is the fundamental flaw of checking only length and character classes: it measures a password's shape, not its scarcity.

This guide covers the two things that should happen at the moment of registration or password change: evaluating the password's real strength, and checking whether it has already appeared in a known breach. The product "Green Bamboo Notes" and the person "A-Tang" in the examples are fictional, used only to make the process concrete. First, the boundary with guides already published on this site: the two-factor authentication guide covers the second lock beyond the password, the Magic Link guide covers logging in without a password, the password-recovery guide covers what to do when a password is lost, and the key-rotation guide covers third-party API keys. This guide covers only the quality gate at registration and password change: is the password the user is typing right now good enough, and has it already leaked?

Strength evaluation: do not count entropy, count how many guesses an attacker needs

The textbook strength algorithm counts entropy: the larger the character set and the longer the string, the higher the entropy. But entropy has a fatal blind spot: it assumes passwords are randomly generated, and real passwords almost never are. A real user's password is usually a familiar word, slightly mangled, plus a few digits or symbols. "Tr0ub4dor&3" scores decently on an entropy formula, yet an attacker never needs to brute-force the whole character space — they have dictionaries, common-mangling tables, keyboard-sequence libraries, and lists of years and names. Scoring by number of guesses is the algorithm that matches the attacker's reality.

The common industry approach follows the idea behind open-source estimators like zxcvbn: split the password into pattern segments, estimate the guessing cost of each segment, and combine them into a strength grade. At minimum, five patterns must be covered: common words and names (dictionary words, brand names, team names); keyboard sequences (qwerty, 1qaz — zxcvbn itself is a keyboard path); dates and years (birthdays, anniversaries, the current year); repetition and simple mangling (aaa, abcabc, swapping o for 0, appending an exclamation mark); and context words (the product name, the company name, the username itself). A password built mostly from these segments may be 12 characters long yet cost only tens of thousands of guesses — less than a second against offline cracking.

Grading and copy matter as much as the algorithm. Use four grades — weak, fair, strong, excellent — and give each grade one actionable improvement suggestion, not just a colored bar. A weak password deserves copy like "This password is very common — try a sentence you have not used anywhere else"; a fair one should name the specific weakness, for example "dropping the year would help"; even a strong one should carry the reminder "do not reuse it on other sites." The strength meter is not the goal; getting the user to pick a better password without frustration is.

One rule is easy to miss: the password must not contain the username, the email prefix, or the product name. Many products only check "password must not equal username" but allow "password contains username." Once an attacker has an email address, the first variation they try is building it into password guesses. The check should be "contains means rejected," and the message must explain why, or users will think the system is broken.

Breach checking: query the whole database with 5 hash characters, and never hand over the full password

The core technique for breach checking is called k-anonymity querying. It works like this: the browser or server hashes the password the user typed with SHA-1 and sends only the first 5 characters of the hash to the breach database service; the service returns all hash suffixes — roughly 800 of them — that share those 5 characters, and the client compares the full hash locally. Throughout the process, neither the full password nor the full hash ever leaves the user's device or your own server; the service learns only that "someone is checking a password whose hash starts with these 5 characters," and cannot reverse that into a specific password.

Several implementation details must be held. First, the check should run on the server, or at least be re-verified there — a front-end-only check is a rule written where users can change it, and bypassing it takes an attacker only a disabled script. Second, never write the plaintext password or the full hash into logs, error reports, or analytics; once a password hash lands in a log, it becomes fresh material for the next breach database. Third, the breach database itself must be refreshed regularly, and its coverage must be stated honestly: you are checking "passwords that appeared in known breach events," not "passwords currently being used by attackers" — the two must not be conflated.

A common implementation mistake is making breach checking a one-time event at registration. The correct approach checks at three moments: registration, password change, and periodic re-checking of stored passwords after login. The last one matters most: a password that was clean at registration may become dirty two years later because of a third-party breach. On re-check, do not brutally sign the user out; the right move is a calm message at their next login — "The password you are using appeared in a data breach event; we suggest changing it" — with a one-click path to the password-change page.

When a password is found leaked: honest copy that does not scare people

Leak-notification copy is the easiest part of this feature to get wrong. Too light, and users ignore it; too heavy, and users believe their account has already been stolen. The recommended copy has three sentences: fact, impact, action. The fact: "This password appeared in a known data breach event." The impact: "That means someone else may already have seen it, making it easier to use it to sign in to your account." The action: "Pick a password you have not used anywhere else; turning on two-factor authentication adds further safety."

Three sentences must not be written. Do not name a specific breach event and date unless you can be 100% sure of the correspondence — a breach database proves only that "this password appeared somewhere," not that "your password leaked in that particular event." Do not write "Your account has been compromised" — breach checking examines the password, not the account's status, and confusing the two creates unnecessary panic and support tickets. And do not nag users with repeated pop-ups when they decline to change — one reminder, one entry point, one recorded state is enough; repeated blocking only pushes users toward "pick anything to get past this."

There is also a policy question: for a password found leaked, is it "blocked" or "warned but allowed"? For registration and password-change flows, block it outright — the user is setting a new password, and the cost of picking another one is lowest, so there is no reason to allow it. For stored-password re-checks, warn and guide — the user is in the middle of normal product use, and the disruption cost of forced sign-out is high, so graduated handling is more reasonable. Using one policy for both scenarios is where many products go wrong here.

Five things not to do: a list more important than the to-do list

First, do not store passwords in plaintext, and do not "protect" them with reversible encryption. The correct practice is a dedicated password-hashing algorithm (such as Argon2id or bcrypt) with a random salt, with the hashing parameters written into your security baseline document and reviewed periodically for upgrades. Second, do not invent your own password rules, such as "must contain one special character and no two consecutive digits" — such rules only push users toward predictable mangling (an exclamation mark at the end) and slow attackers down not at all.

Third, do not force users to change passwords on a schedule unless there is breach evidence. The US National Institute of Standards and Technology (NIST) digital identity guidance no longer recommends periodic forced rotation: its only certain effect is users changing a password to "the old password plus 1." The right approach is "require a change when there is evidence," and breach checking is exactly the mechanism that supplies the evidence. Fourth, do not run strength checking on the front end only — the front end is the experience, the back end is the defense, and both are indispensable.

Fifth, do not show "Password strength: weak" next to the password field and then leave the user stranded. Strength output must come with improvement advice, and that advice should be specific to this password: name the pattern (common word, keyboard sequence, year) rather than offering a generic "please use a more complex password." Users are not unwilling to set good passwords; most of the time they simply do not know why their password is bad.

Acceptance checklist: standards for the registration and password-change pages

Finally, a checklist ready for acceptance testing. Does the password field show real-time strength evaluation, based on guess count rather than length alone? Does the strength copy name the specific weakness and suggest an improvement? Are usernames, email prefixes, and product names rejected when contained in the password? Is breach checking performed at both registration and password change, with queries sending only the first 5 hash characters? Does the server independently re-verify the front-end checks? Are plaintext passwords and full hashes absolutely absent from logs and error reports? Is there a periodic re-check mechanism for stored passwords, and does a hit produce a "fact, impact, action" message? Are newly set leaked passwords blocked outright, while stored-password hits are warned and guided? Is there no rule forcing periodic password changes?

Each item on this list is easy on its own; the hard part is having all of them at once. Password security was never the victory of a single algorithm, but the sum of small decisions across four moments: registration, password change, sign-in, and re-checking. Making "has this password already leaked" a default check every time a password is set costs one hash query, and buys the cheapest line of defense in the whole account system.

The admin's view: rolling it out without annoying everyone

The hardest part of password rules is often not the technology but the rollout. If an admin overnight marks every existing password company-wide as failing and forces everyone to change passwords the same day, the next day brings a pile of help tickets and a wave of "pick anything to get past this" weak passwords. A steadier rollout has four steps. First, enable strength evaluation and breach checking only for new registrations and voluntary password changes; existing users are untouched. Second, silently re-check stored passwords and count only — do not disturb anyone — to learn the number: how many accounts use an already-leaked password. Third, send targeted change reminders to the accounts that hit, with a two-week grace period. Fourth, after the grace period, apply graduated measures to the still-unchanged high-risk accounts — administrators, finance staff, anyone who can touch production data — such as requiring a password change at next sign-in.

The key to graduated handling is crossing "account importance" with "password risk." An ordinary member using a leaked password needs a reminder and guidance; an administrator who can delete production data using a leaked password deserves escalated handling. Doing the reverse — the harshest measures for ordinary members while leaving administrators alone — is the most common inversion in security policy. The rollout schedule should also be announced internally: when it starts, who it affects, and what happens if they do not change — three sentences, stated up front, beat a hundred sentences of after-the-fact explanation.

Password managers and passkeys: making "a good password" the default

Strength evaluation and breach checking solve "blocking bad passwords," but half the problem is "helping users create good ones." A random long password from a password manager passes strength evaluation naturally and almost never appears in a breach database — a randomly generated string colliding with a breach dump is vanishingly unlikely. For product teams, the cheapest investment is to explicitly support password-manager autofill on registration and password-change pages: do not disable pasting, do not break autofill with odd input structures, and do not add scripts that interfere with the password field. Many products demand high-strength passwords while disabling paste, which forces users back to weak passwords they can remember.

The further step is offering passkeys as an alternative sign-in method. Passkeys replace passwords with a device-local key pair, sidestepping the "has this password leaked" question entirely. But note the positioning: passkeys are an upgrade to the sign-in method, not a replacement for password checking. As long as the product keeps a password sign-in path, password checks remain necessary; the more users passkeys cover, the smaller the password path's risk surface. The two complement each other rather than competing. Readers of this site's Magic Link and two-factor guides can see all three as stops on one line: password checking governs "password quality," two-factor adds "a second lock," and passkeys and Magic Links govern "using passwords less."

One mobile detail closes the loop: autofill and password-manager prompts on phone keyboards are often overlooked by developers. If a mobile registration page's password field lacks the correct autofill type, the user's password manager cannot offer to generate a suggestion, and the user must type a memorable weak password on a small keyboard. Setting the autofill type correctly is a one-line change whose effect is equivalent to giving every mobile user a password generator by default.

Pre-launch regression testing: run the full flow with known leaked passwords

Before a password-checking feature ships, run the whole flow against a set of known leaked weak passwords: at registration, is such a password graded weak by strength evaluation, blocked by breach checking, and shown the correct message? At password change, is it blocked the same way? Does a stored-password re-check surface at next sign-in, and does clicking it lead straight to the password-change page? Testing must use public weak-password samples in a test environment — never real users' passwords, because test data mixed with real passwords becomes a new breach source in itself. The pass criteria belong in the release checklist: any failed block, wrong copy, or password trace in logs should stop the release. Bugs in the password flow rarely still look "minor" once found in testing, because this flow guards the first gate of the whole account system.