Login Policy
TL;DR
WordPress login is one of the clearest examples of what WP fail2ban does differently. Instead of treating every failed login alike, it gives you control over which identifiers WordPress accepts, which user information it exposes, and which attempts carry enough context to deserve a different response.
That lets you build a login policy around your site rather than a generic security checklist. You can keep public usernames working throughout WordPress while requiring email addresses for login. You can close enumeration routes when usernames must remain private. And you can turn known-bad or retired identifiers into high-confidence signals for fail2ban.
WP fail2ban Free includes all three controls. Premium lets you configure them through WordPress admin and keeps a persistent event history for investigation.
You choose the combination that fits your site. WP fail2ban gives you the controls to implement it.
Keep public identity separate from login identity
WordPress is a publishing system. Your authors may need a public identity, and your themes, plugins, APIs, and integrations can have legitimate reasons to expose information about them.
WordPress normally accepts the same public username as a login identifier. That is convenient, but it also means an attacker who discovers the username no longer has to guess which account to attack.
WP fail2ban lets you separate those two jobs by requiring an email address for login. The public username can continue to work throughout your site, but it stops being useful at the login screen.
For many sites, this improves login security without suppressing useful WordPress features. It can also remove the need to block user enumeration: you gain little by hiding a username when your site no longer accepts it for authentication.
You still decide whether the change fits your users. People who have logged in with usernames for years may need time to update saved credentials, and a large membership or publishing site may need you to manage the change carefully.
Control what WordPress reveals
If your users still need to log in with usernames, keeping those usernames out of public responses becomes much more valuable. WP fail2ban can close the core WordPress routes commonly used to collect them.
Direct anonymous attempts to enumerate users through the classic author query or the REST users endpoint are blocked and become hard events. Elsewhere, WP fail2ban removes author details from oEmbed responses and suppresses the users sitemap without treating every request as an attack.
This works when the rest of your site can keep the login username private. WordPress still needs to publish author identity as standard metadata, and your theme or another plugin may expose the same value. You can keep the public name distinct from the login username or use email-only login when that separation is not practical.
Turn known-bad identifiers into strong signals
Most failed logins are ambiguous. Your users can mistype a password, present an old saved credential, or simply forget what they changed it to.
WP fail2ban lets you identify the exceptions: identifiers such as admin that should never be used on your site, or old identifiers you have deliberately retired. An attempt to use one becomes an explicit policy violation and a much stronger signal for fail2ban than an ordinary failed password.
Closing enumeration routes cannot make bots forget a username they collected yesterday. Changing and blacklisting it turns that stale information into a useful tripwire—but only after your legitimate users, browsers, and password managers have stopped presenting it.
The blacklist must match the identifiers your policy accepts. If you require email-only login, blacklist email addresses rather than usernames.
More about blacklisted usernames.
Build a policy from three decisions
The three controls let you answer three different questions:
- What identifiers will you allow people to use at login?
- What user information do you want WordPress to reveal?
- Which identifiers do you want to prohibit explicitly?
WP fail2ban lets you answer those questions independently. They are not three security levels to enable in sequence.
Email-only login may remove the reason to hide public usernames. User-enumeration protection matters most when usernames still work at login. The blacklist applies to whichever identifiers your site accepts.
A single-administrator site, a public publishing platform, and a large membership site do not have the same users, integrations, or tolerance for disruption. WP fail2ban gives each of them the controls to implement its own answer.
Give the firewall events worth acting on
Your firewall sees a connection from an IP address. It cannot know whether an identifier is public, accepted at login, or deliberately prohibited. WordPress has that application context, and WP fail2ban uses it to give different events different meanings.
A username submitted after you require email-only login may come from a user with an old saved credential, so WP fail2ban sends it to the soft filter. Repetition can give fail2ban the confidence to act. A direct request to an enumeration route you have closed, or an attempt to use a blacklisted identifier, cannot be legitimate under the policy you defined. That becomes a hard-filter event: a signal a configured fail2ban jail can act on immediately.
When the email-only or blacklist control refuses authentication, the caller receives a plain Forbidden response. WP fail2ban keeps the useful context for your event history and fail2ban rather than returning account information.
