ASVS V6.2.4 requires that passwords set at registration or change are checked against at least the top 3000 common passwords that match your own policy, for example your minimum length. It is a Level 1 requirement.
The phrase "which match the application's password policy" means you only need to keep the list entries that would otherwise be accepted. With a 15 character minimum, most of the top 3000 are already too short and can be dropped.
Think of this control as a tripwire for the lowest effort attacks. It does not stop a determined cracker, but it prevents the passwords that every automated tool tries first.
Why it matters
Credential stuffing and online guessing start with the most common passwords. A blocklist removes the cheapest wins for an attacker.
Look at what attackers actually do. A guessing attack against a live login can try only a few attempts per account before rate limits bite, so they pick the most likely candidates: password, 123456, qwerty, a season and a year. A short blocklist takes those off the table. Credential stuffing works the same way, since many reused passwords are among the commonly used ones.
The cost for you is almost nothing. A set of 3000 strings fits in a few kilobytes and a lookup is instant.
How to implement it
Load the list once at startup into a set and compare using a normalized form.
from pathlib import Path
MIN_LEN = 15
COMMON = {
line.strip().lower()
for line in Path("common-passwords.txt").read_text(encoding="utf-8").splitlines()
if len(line.strip()) >= MIN_LEN
}
def is_common(pw: str) -> bool:
return pw.lower() in COMMON
Use the same function at registration, change and reset. V6.2.12 extends this to breached password sets.
Choose a list and keep its provenance. Many security teams start from a public top password list, then filter it to entries that satisfy their policy. Store the filtered list in version control with a note about its source and date.
Compare case insensitively, and also compare after removing a trailing run of digits and symbols. Users know that Password1! is risky, but they often assume it is fine because it looks complex.
const common = new Set(fs.readFileSync("common.txt", "utf8").split("\n").map(s => s.trim().toLowerCase()));
function isCommon(pw) {
const p = pw.toLowerCase();
if (common.has(p)) return true;
const stripped = p.replace(/[0-9!@#$%^&*._-]+$/, "");
return stripped.length > 0 && common.has(stripped);
}
Call the check in a single shared function used by registration, change and reset endpoints. If you also use a breached password service (V6.2.12), run the local list first because it is faster and does not need a network call.
How to test it
Take five entries from your list and try each at signup, change and reset. All must be refused with a clear message. Then try a long random passphrase and confirm it is accepted.
Write an automated test with a table of known bad inputs and expected outcomes. Include exact matches, different case, and a common word followed by digits. Run the test against each endpoint that sets a password, not just the shared function, to catch routes that skip it. Add a negative case so you know the check is not blocking everything.
In manual testing, try the three flows in a browser and confirm that the message is helpful. It should tell the user the password is too common and invite a longer passphrase.
Common mistakes
-
Checking only at registration.
-
Keeping a list of 100 entries because it was easy to download.
-
Rejecting without explaining, so users try tiny variations.
-
Loading the list on every request instead of once.
-
Applying the list on the client only.
-
Forgetting administrative creation flows, such as invitation links and import jobs, that set initial passwords.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why filter the list by your policy?
Entries below your minimum length are already rejected, so keeping them only wastes memory.
