Harden the WordPress login page

wp-login.php is one of the most targeted URLs on the web. Attackers hammer it with credential stuffing and brute force, and bots probe it for empty or default usernames. The login page is not a place to be novel; it is a place to apply well-understood defaults that stop automation without breaking a normal sign-in. Hardening is about layered controls, not one magic setting.

Where the attack lands

Brute force tries many passwords against a guessed username. Credential stuffing replays username and password pairs stolen elsewhere. Both produce a flood of POSTs to /wp-login.php. Because WordPress does not limit failed attempts by default, a plain installation lets that flood run indefinitely. Two-factor and rate limiting raise the cost so high that attackers move on.

Harden the page

Start with attempt limiting. A plugin or a reverse-proxy rule should lock an IP after a small number of failed attempts and hold failed attempts in the database so a bot that resets its IP still meets a steady lookup cost. Keep the lockout window short, minutes rather than hours, so a user who mistypes a password is not cut off.

Require two-factor auth for administrators and any role with content administration. Time-based one-time passwords (TOTP) are the common default; they defeat credential stuffing because a stolen password alone is not enough to log in.

Reduce the attack surface:

• Do not publish the admin username. Use an email or a non-default login.
• Block xmlrpc.php on the web server or disable its access methods, because XML-RPC has been used to amplify brute force and to run system-multicall flooding.
• Add HTTP security headers that apply to the whole site, including the login page.
• On the reverse proxy or firewall, add rate limiting to the /wp-login.php and /xmlrpc.php endpoints so excess traffic is rejected at the perimeter rather than reaching PHP.

Keep it usable

Hardening must not lock out legitimate users. Anchor the lockout to the account as well as the IP, so a genuine user on a shared or dynamic IP is not blocked when someone else on the same IP was locked. Allow a warm-up path: after a configurable number of failures, require two-factor rather than an immediate hard block. Test that the subscription form or any front-end auth keeps working, and check that email-based password reset flows still deliver mail.

Clean up the obvious footguns: remove the Generator meta tag or hide the API version it leaks if a security scanner flags it, and make sure the default_password_nag reminder does not expose which accounts are fresh.

Monitoring

Watch the server access log for concentrated bursts to wp-login.php from a single source or network. A rise in 401 status codes on that path is a sign of active guessing. If the lockout or two-factor layer keeps an account out through no fault of the user, the fastest recovery is often a host-level check of the reverse proxy, not a plugin toggling.

Related hardening

Login security and the network headers that protect requests are separate layers. Pair the brute-force and two-factor controls here with the site security headers guide for the response-side protections.