Documentation / Policy-Compliant Generated Passwords

Policy-Compliant Generated Passwords

Overview

On a few account-creation flows, nobody types a password — WordPress mints one itself. Left alone, that password has no relationship to your active policy: if the policy requires a special character, for example, a purely alphanumeric generated password fails it, and the new account would be sent straight to a forced reset before it could do anything else.

Teydea Login Security replaces that generated password with one that already satisfies the policy that will apply to the account. If the policy is strict enough that no compliant password can be generated, the original WordPress-minted password is used instead, and the usual compliance check at first login remains the safety net, exactly as it would without this feature.

Where This Applies

The replacement runs on every flow where WordPress mints a password on an account’s behalf: multisite signup activation, the network’s Add New Site screen, the Add New User screen (network and per-site), the network’s per-site Users screen, and open self-registration.

It is only visible to the person receiving the account on the flows that email the generated password itself — multisite signup activation and new-site creation. The other flows email a link to set a password instead, so the account holder never sees or uses the generated value directly; the replacement still runs there, but has no effect the account holder would notice.

Limitations

Where a flow does not yet know which role or site the account will belong to, the site’s default registration role stands in, and a policy targeted at a more specific role may not be satisfied. Rules that compare a password against the account’s own username or display name cannot be evaluated before the account exists and, like any account whose password could not be made compliant, remain enforced at first login instead.

See also: Password Hint, for what is shown on screens where WordPress asks for or mints a password.