Securing WordPress Logins Beyond Passwords

Here is the uncomfortable part first: the attacks that actually compromise WordPress logins mostly do not involve guessing your password. They involve reusing it — credentials leaked from some unrelated service, replayed against your wp-login.php by a botnet that tries a few thousand sites an hour. Or they skip the login form entirely and come in through a stale plugin. A 40-character passphrase does nothing against either.

That does not mean password advice is useless; it means it is step zero, and most guides stop there. This one covers the rest: which attacks target WordPress logins, and which specific defense stops each one. Because security controls that do not map to a real attack are just friction with good PR.

Know Your Attackers (There Are Only Four)

Every login attack on a WordPress site falls into one of four buckets:

1. Credential stuffing — trying username/password pairs leaked from other sites. By far the most successful category, because password reuse is universal.
2. Brute force / password spraying — automated guessing, usually of common passwords against the admin user. Noisy, cheap, mostly stopped by basics.
3. Session and cookie theft — malware or an XSS hole grabbing an authenticated cookie, no password needed.
4. Bypass routes — XML-RPC, the REST API, application passwords, or a compromised admin’s email account used for a password reset.

Keep this list in mind as we go — each defense below names which of the four it actually addresses.

Two-Factor Authentication: The One Non-Negotiable

Stops: credential stuffing, brute force. Weakens: reset-based bypass.

If you adopt exactly one measure from this article, make it this. Two-factor authentication (2FA) means a stolen or guessed password is no longer sufficient — and since stolen passwords are the dominant attack, 2FA removes the dominant attack. The remaining decisions are about which second factor:

• TOTP apps (Google Authenticator, Aegis, 1Password’s built-in) — the sensible default. Free, offline, phishing-resistant enough for most threat models.
• Hardware keys / passkeys (WebAuthn) — the gold standard, because the browser cryptographically verifies the site’s identity. A phishing page that perfectly clones your login cannot harvest a passkey. Worth it for admin accounts on sites that matter commercially.
• Email codes — better than nothing, but note the circular dependency: if an attacker controls the email inbox, they control both the password reset and the second factor. Email-based 2FA is only as strong as the inbox, which should itself have real 2FA.
• SMS — last resort. SIM-swap attacks are a solved craft for targeted attackers.

Practical policy for a small team: mandatory 2FA for every account with Editor role or above, recovery codes printed and stored offline, and one break-glass admin account whose credentials live in a sealed envelope or a password manager vault with emergency access configured. The most common 2FA failure mode is not an attack — it is the site owner locked out after a phone dies, then disabling 2FA permanently out of frustration. Plan the recovery path on day one and you will never be tempted to weaken the lock.

Rate Limiting and Lockouts: Cheap, Effective, Slightly Overrated

Stops: brute force. Slows: credential stuffing.

Limiting login attempts (say, 5 failures then a 15-minute lockout, escalating on repeat offenses) makes bulk password guessing uneconomical. Every serious security plugin offers this; enable it. Two honest caveats:

• Distributed botnets rotate through thousands of IPs, so per-IP lockouts slow them less than the dashboards imply. Pair IP limits with per-username throttling if your plugin supports it.
• Lockouts can be weaponized to lock you out. Make sure your own IP can be allowlisted, or that lockouts never apply to a verified 2FA session.

Close the Side Doors: XML-RPC and the REST API

Stops: bypass routes, and the highest-volume brute force.

The login form is not the only place WordPress accepts a password. Two others matter:

XML-RPC

The legacy API at /xmlrpc.php accepts authentication and — worse — its system.multicall method historically allowed hundreds of password guesses inside a single HTTP request, defeating naive rate limiting. Unless you specifically rely on it (the old mobile apps, some Jetpack features, remote publishing clients), block XML-RPC outright at the server or firewall level. Most sites will notice nothing except quieter logs.

The REST API and username enumeration

Out of the box, /wp-json/wp/v2/users can reveal your account usernames, converting an attacker’s guessing problem from “username and password” to just “password.” Restrict user enumeration (most security plugins do this), and while you are at it: never publish under a username you log in with — set a display name that differs from the login. And retire any literal admin account; it absorbs the majority of untargeted guessing traffic.

Application Passwords: The Feature Everyone Forgets They Enabled

Stops nothing; creates a bypass if unmanaged.

Since WordPress 5.6, any user can generate application passwords — long tokens that authenticate REST API requests without 2FA. They are genuinely useful (that is how many integrations, mobile apps, and automation tools connect), but they are also a standing exception to your login security, and they never expire on their own.

The hygiene rules:

• Audit them quarterly: each user’s profile page lists their application passwords with last-used dates. Revoke anything unrecognized or unused for 90+ days.
• Create integration tokens on a dedicated low-privilege user, not on your admin account. An automation that only reads posts does not need a token that can install plugins.
• If you use no integrations at all, disable the feature entirely with a filter or security plugin.

Protect the Session, Not Just the Door

Stops: session theft.

Once someone is logged in, the cookie is the identity. Three things keep that honest:

• HTTPS everywhere, with HSTS. Any login page served over plain HTTP means credentials and cookies cross the network readable. This should already be true of every site today; verify it anyway, including on staging subdomains, which are the classic gap.
• Reasonable session lifetimes. The “Remember Me” checkbox extends sessions to two weeks. For high-privilege accounts on shared machines, that is generous. A snippet or plugin can shorten admin sessions to a day or two — mild friction, meaningful reduction in stolen-cookie shelf life.
• Log out idle admin sessions and, after any security incident, force-expire all sessions (changing a password does this, as does the “Log Out Everywhere Else” button in the profile).

The Email Account Is Part of Your Login System

Stops: reset-based bypass.

This is the layer people consistently miss: whoever controls an admin’s email inbox controls the WordPress account, because password reset flows through email. Attackers know this, and inboxes are often softer targets than hardened sites. The implications:

• Every admin’s email account needs 2FA at least as strong as the site’s.
• Admin accounts should use email addresses on domains you control, not abandoned free-mail addresses from a decade ago. An expired domain in an admin email is a takeover waiting for a registrant.
• When someone leaves the team, removing their WordPress account matters less than remembering that their email may still receive reset links for shared accounts. (Better: never share accounts. One human, one account, always — it is also the only way activity logs mean anything.)

What About Hiding the Login Page?

Renaming wp-login.php to something secret is the most popular advice in amateur guides and the least important measure in this article. It reduces log noise from dumb bots — genuinely pleasant — but provides no protection against anyone who looks, since the custom URL leaks through redirects, page source, and misconfigured plugins constantly. Treat it as optional tidiness, never as a substitute for 2FA. Security through obscurity is fine as a garnish.

A Layered Setup You Can Finish This Afternoon

Roughly two hours of work, most of it one-time, and it covers all four attack categories. Compare that with the hours people spend agonizing over password length — which addresses half of one.

Closing Thought

Login security is not about building one unbreakable lock; it is about making sure that every category of burglar meets a lock designed for them. Passwords handle the guessers. 2FA handles the credential reusers. Closed side doors handle the API prowlers. Session and email hygiene handle the ones who never touch your login form at all. None of these layers is exotic, none is expensive, and together they move you out of the population of easy targets — which, for the automated attacks that constitute nearly all of the volume, is the whole game.

Photo: Connor Scott McManus on Pexels