All guides

Security

Securing the WordPress login: brute-force protection, two-factor authentication and passkeys

What actually stops account takeover on WordPress: lockouts that cannot be spoofed, a second factor that gates every login path including XML-RPC, and passkeys for the people who hate codes.

4 min readUpdated

What you are actually defending against

Two attacks account for nearly every compromised WordPress admin account:

  • Credential stuffing. Passwords leaked from another site, tried against yours by a bot. No amount of "strong password" advice helps if the user reused one.
  • Brute force. Thousands of guesses against wp-login.php and, more quietly, against xmlrpc.php, which accepts logins too and is where several 2FA plugins historically had a hole.

The defence is layered: slow the guessing down so it is not worth the attacker's time, then make a correct password insufficient on its own. Dragon Login Security does both, and it makes no external requests, so nothing about your users leaves your server.

Step 1: brute-force protection, done right

Install the plugin. Lockouts are on immediately: repeated failed logins from an address trigger escalating lockouts, and allow and deny lists live under Settings, then Login Security.

Escalating lockouts, allow and deny lists, and proxy-aware client IP detection.
Escalating lockouts, allow and deny lists, and proxy-aware client IP detection.

The setting that matters most is the one most plugins get wrong: which IP address counts. By default the plugin uses the direct connection address, which a visitor cannot forge. Only if your site sits behind a reverse proxy, load balancer or CDN should you enable Trust X-Forwarded-For, and when you do, fill in Trusted proxy IPs and ranges with your proxy's addresses. The client is then taken as the first forwarded address that is not one of yours, walking the chain from the right, so a forged header cannot dodge a lockout or lock out someone else. Turning proxy trust on without listing the proxies is how attackers make lockouts pointless.

Coming from Limit Login Attempts (Reloaded) or Wordfence? The import cards at the bottom of the settings tab carry your allow and deny lists across in one click.

Step 2: a second factor for every admin

Each user enrols from Users, then Profile, then Login Security. Three options, and a user can have more than one:

  • Passkeys. Sign in with Face ID, Touch ID, Windows Hello or a hardware security key. Phishing-resistant, nothing to type, and the option most people actually keep using. Requires HTTPS.
  • Authenticator app. Time-based codes from Google Authenticator, 1Password, Authy or any standard app.
  • Backup codes. Single-use recovery codes. Download them at enrolment and keep them somewhere that is not the same laptop.

Per-user two-factor: passkeys, authenticator apps and backup codes.
Per-user two-factor: passkeys, authenticator apps and backup codes.

The property worth knowing: no authentication cookie is issued until the second factor passes. The gate sits at WordPress's own authenticate step, which means it covers XML-RPC and application-password logins as well as the login form. A 2FA plugin that only decorates wp-login.php leaves the back door open.

Enrol the administrators first. Then editors and anyone with plugin-install rights. Subscribers on a membership site can wait unless they hold anything valuable.

Step 3: plan for lockouts before they happen

Someone will lose a phone. Two escape hatches, in order:

  1. Backup codes on the two-factor screen.
  2. The server-side reset, run by an administrator with shell access:
bash
wp dragon-login-security disable-2fa <username>

That removes the user's second factor so they can log in and re-enrol. Note that it exists, and who can run it, before you need it.

Step 4: keep a record

Enable Dragon Activity Log alongside. Logins, logouts, failed logins and profile changes are recorded with the user, time and address, and Login Security feeds its lockouts into the same log. When an account is compromised, the first question is "what did they do", and this is the only place the answer exists. See the activity log guide.

Things this plugin deliberately does not do

  • Hide or rename wp-login.php. It breaks the REST API and application passwords for a benefit that evaporates the moment an attacker reads your HTML. Lockouts and 2FA are the real control.
  • CAPTCHAs on the login form. They punish humans more than bots. Escalating lockouts achieve the same slowdown without the friction.

Making it mandatory

A second factor that is optional is a second factor the busiest admin never enabled. Dragon Login Security Pro enforces enrolment by role, with a grace period or a hard block until enrolled, remembers trusted devices so people are not challenged on every login, re-challenges and alerts when a login arrives from a new address or device, and produces a compliance report of who is and is not enrolled. WooCommerce stores can extend 2FA to customer accounts. The rollout is in enforcing two-factor authentication by role.

Checklist

  • Login Security active, lockouts confirmed by a deliberate failed login
  • Proxy trust off, or on with the proxy ranges listed
  • Every administrator enrolled, ideally with a passkey plus backup codes
  • Backup codes stored somewhere other than the enrolled device
  • Someone knows the disable-2fa escape hatch exists
  • Activity Log recording logins and failed attempts