How To Refuse Breached Passwords With BetterShield?

Check new passwords against Pwned Passwords without sending them, see which forms are checked, and what happens when the service cannot be reached.

With BetterShield, check new passwords against Pwned Passwords without sending them, see which forms are checked, and what happens when the service cannot be reached.

What it does

In BetterShield, Leaked password check turns away a new password that already appears in a published breach, at the moment someone chooses it. It never affects signing in, and never refuses, resets or reports a password an account already has. It is under Signing in on BetterShield › Protection › Login & Access, and it starts off. This page is the reference for the fix. Password rules covers the password policy that runs before it, with a table of every form each rule applies to; WordPress breached password check explains the exchange step by step.

Five characters leave your site, nothing else. The new password is turned into a one-way hash on your server, and only the first five characters of that hash go to Pwned Passwords. Several hundred published hashes come back, padded so their number reveals nothing, and the comparison happens on your server. No password, account, address or identifier is sent.
A match is refused with one sentence: “This password appears in a published breach. Choose a different one.” Otherwise the form says nothing.
The password policy goes first. A password it refuses never causes a request to leave the site.
An unreachable service never blocks anyone. If Pwned Passwords does not answer within five seconds, the password is allowed and the activity log records that the check did not run. BetterShield then waits a minute before asking again.
Nothing about the password is stored. The service’s answer is kept for five minutes, so fixing a typo on the same form does not ask twice.

Where it checks

It checks a password only when the person choosing it is signed in:

the profile screen: your own password, an administrator setting someone else’s, or adding a user;
a store’s account details page;
an account created or changed through the REST API, for WordPress users and a store’s customers;
a reset form, or a registration form that asks for a password, when the person completing it is signed in.

It never checks a form a signed-out visitor fills in, a store’s checkout, WP-CLI, importers, application passwords, or signing in. In the fix’s own words: “A visitor’s registration or reset form never waits on an outside service.”

It runs inside WordPress, so it works on any web server. Safe mode pauses it, and it stops while BetterShield is deactivated.

Open BetterShield › Protection › Login & Access and find Leaked password check under Signing in.

Refuse new passwords that appear in published breaches: saved state and available controls in BetterShield. — Review the state and choices shown on your own site before applying a change.

Step 2: Refuse Breached Passwords

Press Preview the change to read what it does. Nothing changes.
Turn the switch on. The row reads “Checked when somebody signed in sets or changes a password. Signing in is never affected.”, with On since and Undo never expires.

It has no options. Monitor first cannot measure this fix: its panel says to rely on the preview, a staging copy and undo instead.

Before it applies

Like every Signing in fix, applying it first checks your way back in: a working recovery link or unused recovery code, checked within the last day. If that fails, Check the way back in first offers Check now (or Open Recovery) and Go ahead anyway, which is logged. See Set up recovery. Applying needs a signed-in browser, not an application password.

From WP-CLI

wp bettershield harden breached_passwords --dry-run
wp bettershield harden breached_passwords --user=admin

A connected AI assistant can only propose this fix, as a plan you agree to. See WP-CLI commands.

Recommended settings

We recommend turning it on, on every kind of site, with the password policy kept on beside it. It costs a signed-in person at most five seconds while they set a password, and costs visitors nothing.

Site	What we recommend
Store (WooCommerce)	On. Customers changing their password on the account page are checked; sign-up and checkout never wait on it.
Membership or course site	On. A visitor’s sign-up form never waits on the outside service, so new members are not slowed.
Agency or many sites	On everywhere. Export settings on Settings › General carries it to the next site.

What it can break, and how to undo

Nobody loses access. Existing passwords are never refused, reset or reported, so nobody is locked out by it.
Someone choosing a password may be refused and have to pick another, which is the point.
It depends on an outside service. While Pwned Passwords cannot be reached, passwords go through unchecked, and the log says so at most once an hour.
Another plugin checking passwords. If another plugin already listens on the same forms, the row says so before you apply. Nothing breaks: if the other plugin refuses first, BetterShield does not ask, and removing either leaves the other in place.

To undo, turn the switch off. Nothing else changes. Undo needs a signed-in browser, and your password if Ask for my password before removing a protection is on. From the terminal: wp bettershield harden breached_passwords --undo --user=admin.

Final Outcome

The row. The line above, and “This one has no effect a page view can check, so it is reported from your settings.”

A test. On your own profile, try a password you know has been published that the password policy would accept: the form answers with the breach sentence, and your password stays as it was.
The activity log. “Password refused: it appears in a published breach” (Low) names only the account the password was for: never the password, its hash, or how often it was published. “Password list check could not be made” appears at most once an hour while the service is unreachable. Applying and undoing are “Hardening applied” and “Hardening undone”.
Findings. No finding opens while it is off. While it is on, Some protections that are switched on are not working (Medium) names it if it reads as on but is no longer in force, for example because another plugin took it off. Some people still use passwords weaker than your password rules belongs to the password policy, not to this check.

On multisite

Each site has its own switch, and a password is checked when it is chosen on a site where the fix is on.

This is how you can refuse breached passwords with BetterShield.

Getting Stuck? Feel free to contact our Dedicated Support Team.