Check a Password Against a Common-Password Blocklist — Free Tool

Every time someone registers with a password like hunter2, changeme, or yankees, your platform inherits their risk. The Common Password Blacklist Checker gives you an instant verdict on whether a password has already been exposed in known data breaches or flagged in widely circulated lists of weak choices — the insight that lets you enforce a genuinely protective password policy before a compromised credential ever touches your database. Whether you are hardening account registration flows or auditing existing user login details, understanding what this tool returns and why it matters is the first step toward real account security and improved password security.

Why Pwned Passwords Put Your Accounts at Risk — and How to Check Common Password Exposure

Password reuse is one of the most persistent and damaging habits in cybersecurity. When a user picks a password that has already appeared in large-scale breaches, every account they protect with it becomes vulnerable — not because of any weakness in your system, but because attackers already possess that credential. The consequences for user protection, account integrity, and your organisation's reputation can be severe.

When login details are exposed in breaches, they flow into underground markets and are compiled into breach databases containing millions of previously breached passwords. Attackers then cross-reference these datasets against live services, turning old data breach incidents into ongoing threats. NIST guidelines specifically recommend checking new passwords against a dictionary of known-bad choices during account registration — a requirement codified in Special Publication 800-63-3: Digital Identity Guidelines. Following these security guidelines helps organisations comply with guidelines for safe credential management.

"Check new passwords against a dictionary of known-bad choices. You don't want to let people use ChangeMe, thisisapassword, yankees, and so on." — Naked Security @ Sophos, echoing the NIST requirement in Special Publication 800-63-3.

This NIST requirement reflects a mature understanding of threat intelligence: attackers do not need to brute-force a password they already know. By maintaining a banned password list and checking every incoming credential against it, you comply with digital identity standards while actively eliminating weak choices from your environment before they cause harm.

How Password Spray Attacks Exploit Common Choices

Password spray attacks are a particularly dangerous class of attack precisely because they exploit the predictability of human behaviour. Rather than hammering a single account with thousands of guesses — which triggers lockout policies — attackers use tools that predict common patterns across a vast number of user accounts. Because these passwords appear in virtually every common password list ever compiled, even a modest collection of weak entries can unlock a significant percentage of accounts at any given service.

The attack is low-noise by design. By spreading attempts across accounts rather than concentrating them, attackers avoid detection thresholds while still achieving high success rates. Services that dynamically ban known-bad choices at the point of account registration remove the very ammunition these attacks rely on. A password spray becomes far less effective when your users simply cannot set the passwords that appear on attacker wordlists — making the banned password check a direct form of attack prevention.

What Happens When a Pwned Password Is Found in Known Breaches

When a credential lookup returns a positive match — confirming that a password appeared in breaches — the stakes are immediate. The same email and password combinations that surface in one breach are almost always tested against other platforms, a technique known as credential stuffing. Attackers automate login attempts at scale, using leaked login details to compromise accounts across multiple services without any new hacking required.

The practical consequences of ignoring pwned passwords include:

• Account takeover — attackers gain full control of user accounts using login details obtained from breached datasets, enabling identity theft and fraud.
• Credential stuffing campaigns — automated bots test exposed login pairs against banking, e-commerce, and enterprise portals, exploiting reuse habits at industrial scale.
• Brute-force exposure — weak passwords are trivially included in any brute-force wordlist, meaning accounts using them face elevated risk from every direction.
• Regulatory and compliance failure — failing to prevent use of vulnerable passwords can breach data privacy obligations and expose organisations to audit findings.

This is why a breach checker is not a luxury feature but a fundamental component of modern access control and identity management. Detecting breach exposure before a credential is accepted — rather than after an incident — is the only posture consistent with zero trust principles and industry-leading protection standards. You can check password security at the point of registration to prevent these issues entirely.

Integrating the Checker to Blacklist Common Passwords via API and Collection Files

Embedding a common password blacklist checker into your registration flow requires only a few steps: placing the library include, setting up your collections directory, and calling two straightforward API functions. NBP — NIST Bad Passwords — is a freely available JavaScript library designed precisely for this web integration use case, and its API usage is deliberately simple so that any developer can implement it without specialist infosec knowledge.

Initialization and Collection Setup for the Global List

Begin by placing nbp.min.js inside your webroot JavaScript directory and creating a dedicated collections folder alongside your register page. This directory stores compiled bloom filter files sourced from SecLists by Daniel Miessler — the same password sources that power the demo, which uses SecList's 1,000,000 most common password list. The inbuilt password lists include:

• mostcommon_100
• mostcommon_500
• mostcommon_1000
• mostcommon_10000
• mostcommon_100000

Your directory layout should follow this structure exactly, with the library inside js/nbp/ and the collections at the site root level:

webroot/
├── css/
├── js/
|   ├── nbp/
|       ├── nbp.min.js
├── collections/
    ├── mostcommon_10000
    ├── mostcommon_100000
    ├── ...
├── index.php
├── register.php

The collections folder path you specify during initialization must match this layout. In a custom collections scenario, you pass the relative path as the second argument to NBP.init(). Each collection file is named according to a strict list count format: your list_out name must follow this format: [listname]_[list_count], i.e. my_custom_list_600. This naming convention allows the library to correctly parse the collection size and allocate bloom filter storage accordingly.

Building your own password list is straightforward. Your raw list should contain one password per line — password separated by new lines — making it simple to build own password list from any source. Run the build script from the build_collection directory and move the output into your collections directory:

# Assuming pwd is git root
cd build_collection
node index.js raw_list_in list_out
mv list_out ../collections/.

The NBP library internally uses lzstring compression to compress raw bloom filter contents to UTF-16 compression format. Compressed collections are then held in a localstorage store, which prevents unnecessary downloads on repeat visits and significantly improves user experience on your registration page. The stored hit ratio in production is therefore very high once a user's browser has fetched the collection once.

API Access and Calling the Check Function Against Known Breaches

With your directory layout in place, initialization via NBP.init() configures the library for your environment. The full function signature is:

NBP.init([collection_name = "mostcommon_10000"] [, collection_folder_path = "collections/"] [, cache = true]);

The three parameters are: collection name (which list to load, defaulting to mostcommon_10000), collection folder path (the relative path to your collections directory), and a boolean cache flag that controls localstorage behaviour. To load the largest inbuilt list from a custom path with storage enabled, your setup call looks like this:

NBP.init("mostcommon_100000", "register/nbpcollections/", true);

Once initialised, password evaluation happens through a single call to NBP.isCommonPassword(). Pass the candidate password as a string argument and the library returns a boolean indicating whether it appears on the loaded list. A practical demonstration with a classic example:

NBP.isCommonPassword('hunter2');

Because hunter2 is one of the most recognisable entries in virtually every common password list, this call returns true — triggering the Oh no — pwned! response state in your UI and prompting the user to choose a different input. The implementation details are clean: NBP.isCommonPassword performs a bloom filter lookup against the in-memory collection, making the check common password operation near-instantaneous even for the largest 1000000 passwords list.

Enterprise and local deployment: For organisations operating in hybrid scenarios — where data sovereignty or air-gapped environments prevent use of external APIs — NBP supports fully on-premises deployment. Load your own curated password list, host the collections directory on internal infrastructure, and the library functions identically. This makes it suitable for hybrid cloud and on-premises hybrid architectures without any changes to the implementation details or API integration code. Review license requirements before deploying in commercial products — the library is publicly available but specific usage terms apply.

For services requiring a live check against breached datasets at internet scale, the freely available HaveIBeenPwned password API is the recommended complement. It handles over 18 billion requests monthly — processing billions of requests — through Cloudflare's globally distributed infrastructure spanning 335 edge locations across more than 125 countries. This global network delivers lightning-fast responses while minimising latency for users worldwide, with a stored hit ratio exceeding 99.9% ensuring high availability for your password validation service. The api documentation covers the range search endpoint in full, and the Pwned Passwords password downloader lets you take the entire offline corpus on-premises if needed.

Integrating a password lookup into your registration flow is not just a developer convenience — it is a measurable improvement to your organisation's overall protection posture. By rejecting vulnerable passwords at the point of account registration, you prevent the accumulation of reused weak choices across your user base, reducing breach exposure, satisfying nist compliance obligations, and demonstrating to users that you take online safety seriously. Pair this password validation step with multi-factor authentication and a password manager recommendation — tools like 1Password offer strong unique password generation — and you give your users every advantage in maintaining robust login protection across all their accounts.

For teams maintaining active directory or Azure AD environments, the equivalent enterprise feature — Microsoft Entra Password Protection — applies the same two-layer approach using a global banned password list combined with a custom banned password list of organisation-specific banned terms. This enterprise implementation also supports self-hosted agents for hybrid scenarios, extending the same password enforcement and login protection capabilities to Windows Server domain controllers. Whether you are an it admin managing a corporate directory or a developer building a consumer web application, the principle is identical: eliminate weak passwords at the gate, enforce a strong password policy, and make password audit a regular practice rather than an afterthought.

From a web protection and threat prevention perspective, the naked security guidance from Sophos and the formal nist special publication 800-63-3 requirement converge on the same conclusion: a banned list filter at account registration is no longer optional. It is the baseline expectation of responsible access control, essential for breach prevention, and one of the simplest ways to raise your password security posture without adding friction for legitimate users. The password filter works silently in the background — users who choose strong, unique passwords never see a rejection. Only those reaching for weak passwords are redirected, and that redirection is the entire point: prevent vulnerable passwords before they become your next incident, and integrate password check logic into every account registration flow you own.