All 22 Login Security sections
Refusing a weak password
Off by default, on the Settings screen under The password itself.
Everything else here counts wrong passwords. None of it helps if the right one is password123 — five tries is plenty when the first guess works. This is the only part of the plugin that has anything to say about the password itself.
It runs at the two moments a WordPress site sees a password in the clear: when somebody sets or resets one, and when somebody signs in with the one they have. Four rules:
| Refused | Why |
|---|---|
| Shorter than the length you set | Twelve of anything beats eight of anything. The minimum is eight; the default is twelve |
| The usual list, decoration and all | Password1! is password with a shift key. Trailing digits and punctuation are stripped, and the obvious letter-for-number swaps undone, before the comparison |
| Your username, your email name, or this site's name | The first thing anybody guessing tries after the username itself |
| Keyboard runs, rows of digits, one character repeated | qwertyuiopasdf, 190219021902, aaaaaaaaaaaa. Measured as the longest stretch, so five letters of the alphabet inside a passphrase is a coincidence rather than a refusal |
Applies to is the setting that matters on a shop. People who can change the site is anybody who can edit a post or a setting; Everybody with an account includes every customer. A refused checkout because somebody's password was chelsea is a worse day than the account it protected, and that account cannot edit a line of the site.
Every form, including WooCommerce's#
A password gets set in more places than most plugins check, and on a shop the ones that matter are not WordPress's:
| Where | Covered |
|---|---|
| Users → Profile, and an administrator editing somebody | Yes |
| The wp-login.php reset form | Yes |
| WordPress registration, where a site allows it | Yes |
| My Account → Account details on a WooCommerce shop | Yes |
| My Account → Lost password on a WooCommerce shop | Yes |
| WooCommerce registration | Yes |
The WooCommerce ones are worth naming because they are easy to miss and the miss is silent. Woo's reset form does fire the same WordPress hook, but posts the password under a different field name — so a plugin reading only WordPress's name runs its rules, finds nothing, and approves every password on the shop. That is worse than no check at all, because the setting says it is on.
The passwords already on your site#
It cannot read the passwords already on your site. WordPress stores a hash, which is the entire point of a password hash, and nothing can read them back, including this plugin. Anything claiming to sweep them is either wrong or running a password cracker against your own database.
It judges each one the next time its owner signs in. At that moment the password is in the clear for the length of the sign-in, after WordPress has said it is right, and the same four rules run on it. Only for the people Applies to covers: with People who can change the site, the default, a customer's password is not looked at. A password the rules refuse leaves a note on the account: when it was first found, which rule, and, for a password that was too short, the minimum length it fell short of. The password itself is never stored, written to the log or compared with anything but the rules, and neither is its length.
What the person sees:
- in wp-admin, on every screen, a notice: Your password is one this site's rules now refuse., which rule, and Choose a new password, which opens the password on their profile;
- on a WooCommerce shop's My Account page, the same notice with a link to Account details, for customers when Applies to is Everybody with an account.
Make them change it before doing anything else, under the switch, is off by default, so people are only asked. Switched on, somebody with the note is kept on their profile until they choose a new password: every other admin screen sends them there. Signing out, and anything the profile itself needs, still work, and an administrator can still reach this plugin's screens to switch it back off. A customer is kept on My Account → Account details while they are in My Account; the rest of the shop, checkout included, is left alone.
Choosing a new password takes the note away, on the profile, the reset link, WooCommerce's Account details or anything that calls WordPress's own wp_set_password(). Signing in again with a password the rules accept takes it away too. Somebody whose role the rules no longer apply to is not asked, counted or listed, and signing in no longer looks at their password; the note stays out of sight until the rules apply to them again or they choose a new password.
Lowering the minimum length, Shortest allowed, stops asking the people whose password was only too short for the old one. Found short of 14 characters, a password may well have 12, which passes a minimum of 10, or 9, which does not, and the note cannot say which. So from the moment you save a lower minimum they are not asked, counted or listed, and their next sign-in measures the password against the new one: still too short, they are asked again. Raising the minimum keeps asking them, with the new length in the sentence. A note about any other rule is not affected by the length.
Notes made by earlier versions of the plugin did not keep the length. On a single site, the first time you change Shortest allowed after updating, each of them is given the minimum you had until then, and from there they work as above. If you had already changed the minimum since such a note was made, it can be out of step until that person next signs in and the password is measured again. On a network, those notes are asked about on every site until the person next signs in.
Where to see who has one:
- Users → All Users: a Weak password link above the list, with a count, narrows it to them, and their Second step cell says Weak password underneath. On a site WordPress calls large, the link has no number;
- Settings → The password itself says how many accounts signed in with a password the rules refuse;
wp login-security weaklists them with their roles, since when and which rule.
All three count only the people being asked: the roles Applies to covers on this site.
Somebody who never signs in is never judged: an editor who has not signed in since you switched the rules on is still unknown. Users → Send password reset is still the way to reach them.
It is not done for an application password, which is not the account's password, nor over XML-RPC. On a network the note is kept against the person rather than a site, so it reflects the rules of whichever site they signed in to last where the rules apply to them. Somebody with no role on the site they sign in to is not judged there, and each site counts and asks only the people whose role on that site the rules cover. A password found too short is asked about only on sites whose minimum is at least the one it fell short of: found short of 14 on one site, it is not mentioned on a site that asks for 8.
Why there is no breach-database lookup#
The usual way to do this properly is Have I Been Pwned's range API, and it is genuinely clever: only the first five characters of the SHA-1 hash ever leave the site, so nobody learns the password. It is still a request to somebody else's server in the middle of somebody changing their password — one more company in that path, and one more thing to hang when their server is slow.
The rules above are local and instant, and they catch what actually turns up on your own Who has tried screen. Nothing is sent anywhere.
Still stuck? Ask the developers who wrote it. We aim to reply within one business day.