Login Policy » Block blacklisted usernames
TL;DR
WP fail2ban lets you declare login identifiers that should never be used on your site. It refuses an attempt with a plain Forbidden response and writes a hard-filter event that a configured fail2ban jail can act on immediately.
You can prohibit obvious bot favourites such as admin, turn deliberately retired usernames into tripwires, or prevent normal login for an account that should only be used by trusted backend processes.
WP fail2ban Free includes the control, configured in wp-config.php, and writes prohibited attempts to the hard filter. Premium lets you manage the policy through WordPress admin and keeps a persistent history of tripwire hits.
Declare identifiers that should never be used
Automated attacks often try predictable usernames such as admin. If your site has no account with that name and never intends to create one, there is no reason to treat an attempt to use it as an ordinary login failure.
WP fail2ban lets you make that judgement explicit. Add the identifier to the blacklist, and WP fail2ban refuses normal WordPress authentication and writes the attempt to the hard filter. The response does not return account details; the useful context remains with your site and fail2ban.
An unknown username might be a mistake. A prohibited identifier is a direct violation of a policy you have already defined.
Make old attacker data work in your favour
Suppose a username has been public for years and now attracts constant login attempts. Closing user-enumeration routes can stop WordPress revealing it to new attackers, but it cannot remove the username from lists that bots have already collected.
You can change the user's login identifier, then blacklist the old one. The information held by the attacker has not merely become outdated: it has become a tripwire.
Every subsequent attempt tells WP fail2ban that the request is using a credential your site has deliberately declared invalid. You have turned stale attacker data into a strong signal instead of waiting for it to disappear from circulation.
Match the blacklist to your login policy
The blacklist applies to the identifiers your site accepts for authentication. If people can log in with usernames, blacklist the usernames that must never be used. If you require email-only login, blacklist the corresponding email addresses instead. A username that WordPress no longer accepts at login cannot act as a tripwire there.
Email-only login, user-enumeration protection, and blacklisted identifiers answer different questions. The blacklist should reflect the policy your site actually uses, not a generic collection of suspicious names.
Keep service accounts off the login path
Some service accounts need to remain available so trusted code can act as them, but should never accept normal login credentials.
Blacklisting the identifier refuses authentication through the normal WordPress login path without deleting or disabling the account. Trusted code that establishes the user without authenticating those credentials can continue to use the account for its intended job.
This is an advanced policy whose suitability depends on how the integration establishes the user.
Retire identifiers carefully
A retired identifier becomes a strong signal only when it has no legitimate use left.
People, browsers, password managers, documentation, and integrations may continue presenting an old credential after you change it. Once you blacklist that value, WP fail2ban must treat every attempt alike because you have declared that none can be legitimate.
Plan the change, update the people and systems that use the identifier, and give saved credentials time to catch up. Only then should you promote the old value from an obsolete credential to a tripwire. WP fail2ban can act decisively because you decide when the ambiguity has gone.
