Documentation / Weak Password List

Weak Password List

Overview

The weak password list feature checks every new password against a built-in list of over 100,000 commonly used weak passwords. If a user attempts to set a password that appears on this list, the password is rejected.

Enabling the Rule

1. Navigate to Settings → Login Security.
2. In the Enabled rules section, enable Check user’s passwords against the weaklist.
3. Click Save all settings.

When enabled, the plugin checks passwords during:

• Password changes on the User Profile page
• Password resets via the reset form
• New user registration
• Login (to detect non-compliant existing passwords)

How It Works

The plugin ships with a text file containing over 100,000 of the most commonly used passwords. When a user sets or changes their password, the plugin compares it against this list. If a match is found, the password is rejected and the user sees an error indicating the password does not comply with the password policy.

The list is read line by line to keep memory usage low, which helps limit the cost of checking large password lists.

When the List Cannot Be Read

The list ships inside the plugin, so a site that cannot read it has an incomplete installation, file permissions that deny the web server access, or an open_basedir restriction in the way. A file left empty by an interrupted upload or a half-finished deployment counts as unreadable too, since there is nothing in it to match a password against. Reinstalling the plugin should restore the file.

Until it is restored, the rule cannot tell a weak password from any other one. The Weaklist screening section of the General tab decides what the plugin does in the meantime:

• Reject passwords with a message saying the password could not be checked and asking the user to try again (fail-closed) — the default. Rejecting refuses every password someone chooses to set, including a new registration and a password an administrator sets for another user. A password set from a reset link the user was sent goes through without being checked. Signing in is not affected either way.
• Accept passwords without weaklist screening (fail-open) — passwords are accepted without being checked against the list.

Two exemptions keep a rejecting site from locking everyone out. Password policies are re-checked at sign-in, but a list that cannot be read never refuses a password a user already has: refusing there would sign every covered user out, including the administrator who would restore the file. A user finishing a password reset is exempt for the same reason — every request sends them back to that form, so refusing every password there would leave the account with nothing to set. Their new password is accepted without being checked against the weaklist, which is the cost of keeping the reset usable.

Below the rule toggle in each password policy, a status indicator shows whether your server can currently read the list, with a Retry option and a link to Open Site Health. The Weaklist readable Site Health test flags an unreadable list whichever behavior you pick, so you do not have to wait for someone to attempt a password change to find out. It reports critical while an active policy enables this rule, and recommended when no active policy does, because nothing on the site reads the list in that case. See Site Health Check.

Custom Weak Password Lists

Developers can extend the built-in list by providing additional passwords through the password_requirements__custom_password_weaklist filter. See Hooks and Filters for details.