WordPress password policy: length, breach lists and sign-ups

A WordPress password policy decides what a password has to be before your site accepts it. WordPress shows a strength meter while someone types, but the meter is guidance. A policy turns it into a rule, and a good one does that without getting in the way of the people who use the site.

This guide covers what makes a password policy sensible (length, obvious passwords and breach lists), how BetterShield’s policy and breach check work, what they deliberately leave alone, and how to test a rollout on a store or membership site.

Quick summary

• Length does more for a password than rules about symbols and capitals. A few unrelated words make a long password that is easy to remember.
• A password that appears in a published breach is weak whatever its length, because people reuse passwords across sites.
• A good policy checks a password when it is chosen, and leaves signing in alone.
• In BetterShield, Ask a minimum standard of new passwords on Settings › General is on by default: 8 characters for most accounts and 12 for admins and editors.
• Leaked password check adds a breach check, and is off until you turn it on.
• Older passwords below the bar keep working. They are flagged, never blocked.

Why length beats complexity rules

Rules such as “one capital, one digit, one symbol” feel strict, but they push people toward the same shapes: a word with a capital at the start and a digit and a symbol at the end. Those shapes are the first thing guessing tools try, so the rule adds less than it seems to.

Length works differently. Additional unpredictable characters expand the possible choices; padding a familiar word or repeating a pattern is much less useful. A passphrase made from randomly selected unrelated words can be long and memorable. A familiar quotation or a phrase chosen for its obvious meaning can still be guessed. A password manager’s random suggestion is better still, because nobody has to remember it at all.

That is why BetterShield’s policy asks for length and refuses predictable passwords, rather than demanding particular characters. Its own hint to someone whose password is too short says it plainly: “A few unrelated words with spaces between them passes easily.”

Why breach lists matter

People reuse passwords. When another website leaks its accounts, the email addresses and passwords from that leak get tried on other sites, including yours. A reused password can be long, mixed and unusual and still be on one of those lists.

No length rule can see that. A breach check can, by comparing a new password with passwords already published from breaches. Done well, the password itself never leaves your site. Our guide to the WordPress breached password check explains how that works and what is sent.

What a sensible WordPress password policy looks like

1. A minimum length, higher for the accounts that can change the site. An administrator’s password guards everything; a customer’s guards one account.
2. No obvious passwords: nothing built from the username, the email address or the site’s own name, no very common words, no keyboard runs.
3. No published passwords, checked against breach lists as they are chosen.
4. No expiry. Making people change passwords on a schedule tends to produce small, predictable edits. Change a password when there is a reason.
5. Checked when a password is chosen, never at sign-in. A rule that refuses a password someone already has locks them out of their own account.
6. A second factor for staff. A policy makes passwords harder to guess; two-factor authentication means a password alone is not enough.

A better password workflow

Choose, check, protect the sign-in

Each step addresses a different weakness.

1. 01
   Choose a unique secret

   Length plus unpredictability.

2. 02
   Check the new password

   Policy and breach lists differ.

3. 03
   Protect its use

   Add another factor.

Choose a unique secret

What this means

Prefer a password manager or randomly selected unrelated words. A long quotation, name or repeated pattern can still be predictable.

Your next check

Use a different password for this account and its recovery mailbox.

Check the new password

What this means

The local policy checks length and predictable patterns. The optional breach check looks for known exposure on the supported signed-in forms.

Your next check

Test the forms people actually use; checkout, imports and signed-out resets have different coverage.

Protect its use

What this means

A length rule does not stop phishing or reuse of a stolen session. Two-factor or a verified passkey adds sign-in protection.

Your next check

Enroll privileged accounts and verify recovery before requiring the new sign-in method.

How BetterShield’s password policy works

The policy is on BetterShield › Settings › General, under Password policy. Change the numbers and press Save policy.

The higher length applies to the Administrator and Editor roles, to any role that can manage settings, edit users or promote users, and to super admins on multisite.

Beyond length, the policy refuses a new password that is built from the account or the site (the username, email address, display name, site title or domain), built around a very commonly guessed word, or one repeated or sequential run such as “12345678”. Digits and symbols added at the start or end do not hide the word: “Password-2026” is thirteen characters, and it is still refused as a common word.

Each refusal says what is wrong and what would pass. A common word, for example, gets: “This password is built from one of the most commonly guessed words. A password manager’s suggestion, or a few unrelated words, passes.”

The policy runs wherever someone chooses a password: a reset form (WordPress’s or a store’s, which is also how a new account sets its first password), the profile screen, including an administrator adding a user, a store’s account details page and registration form, and the REST API. It does not check application passwords, accounts made by imports, WP-CLI or other plugins in code, or a password set at a store’s checkout. Every place it applies is listed in Password rules.

The breach check alongside it

Leaked password check is a fix under Signing in on BetterShield › Protection › Login & Access. It runs after the policy, so a password the policy already refused never causes a request to leave the site.

It checks a password when the person choosing it is signed in: on a profile, a store’s account page or through the REST API. Only the first five characters of a one-way hash leave your site, and the comparison happens on your server. If the service cannot be reached, the password is allowed and the activity log says “Password list check could not be made”. A published password is refused with “This password appears in a published breach. Choose a different one.”

What it does not do: sign-in stays as it was

Neither rule ever applies at sign-in. A password chosen before the policy existed keeps working, and nobody is forced to reset it.

Instead, BetterShield notices. When someone signs in with a password that falls short of the current policy, their account is flagged, and two things follow:

• Findings shows Some people still use passwords weaker than your password rules, rated Low, or Medium when one of the accounts is an admin or editor. It lists a count, not names.
• The person sees a note on their own profile: “Your password is below the standard this site now asks of new passwords.” Nothing is blocked, and the flag clears when they choose a new one.

Raising the minimum does not invalidate existing passwords. It applies when someone next chooses a password on a supported form, so test those forms before changing a busy site. The finding tells you how many accounts have signed in with a below-policy password.

Rolling it out on a store or membership site

Stores and membership sites have the most accounts and the most sign-ups, so the order matters.

1. Settle the numbers first. Separate the shipped defaults from your chosen policy. Consider at least 15 where a password can be used alone, then test usability with password managers and the actual customer forms.
2. Tell your staff. They meet the higher bar the next time they change a password, and a password manager makes that painless.
3. Try your own sign-up form. Register a test account with a short password and read the message. On a store, the registration form is checked when customers choose their own password, and the message explains what passes.
4. Turn on the breach check. It never runs on a sign-up or reset form filled in by a signed-out visitor, so new customers and members never wait on it. It covers people changing a password once they are signed in.
5. Watch Findings for a week. Some people still use passwords weaker than your password rules shows how many accounts still have older passwords. If it is Medium, ask those admins and editors to change theirs.
6. Remember the checkout. A password a customer sets while placing an order is not checked there. If it falls short, the account is flagged the first time it signs in, like any older password.

If you also run limits on sign-in attempts, the two work together: the policy makes passwords harder to guess, and the limits make guessing slow.

Choose lengths deliberately, then test every form

The shipped defaults describe the plugin; they are not a universal recommendation. For a site choosing a fresh policy, we recommend a minimum of 15 characters wherever a password can authenticate on its own, with password-manager support and no arbitrary composition rules. NIST’s current guidance requires at least 15 for a password used alone and permits at least 8 when it is only used within multi-factor authentication. This is useful design guidance, not a claim that configuring one setting makes a WordPress site compliant. See NIST’s password requirements.

Enabling optional two-factor for some staff does not make every customer password part of a mandatory multi-factor process. Review the real sign-in and fallback paths before choosing a lower minimum.

Test the policy on staging with disposable accounts:

Keep a record of the forms that bypass the policy and ask the responsible developer how those paths should enforce your chosen standard. Raising a number in settings does not cover an excluded form.

Worked example (fictional): a membership site requires two-factor for administrators but offers customers password-only sign-in. The owner chooses a 15-character minimum for those customer passwords, then tests registration, resets and account changes. A custom checkout still accepts a shorter password because it uses an excluded path. The owner records that gap and has the checkout integration corrected before describing the policy as site-wide.

Common mistakes

• Requiring symbols instead of length. It produces predictable passwords. Ask for length and refuse the obvious.
• One bar for everyone. Customers and administrators guard very different things. Use both lengths.
• A very long minimum for customers. Test form guidance and password-manager support instead of assuming a short minimum is the only way to make sign-up usable.
• Forcing everyone to reset at once. Nothing about an older password changes when you turn the policy on, and the finding shows who to ask.
• Turning the policy off because the breach check is on. They catch different things, and the policy costs no outside request.

Frequently asked questions

Conclusion

A WordPress password policy works best when it asks for length, refuses what is obvious or already published, and never stands between someone and an account they already have. Set the two lengths, turn on the breach check, and let each password meet the bar the next time it changes.

BetterShield is free on WordPress.org. Password rules lists every option and where each rule applies.