Stopping login attacks

The short answer

Bots are trying passwords against your login page all day, on every WordPress site in the world. Most fail. The ones that succeed get in through weak or reused passwords and the lack of a second check.

Three things stop almost all of them: a long unique password for every administrator, two-factor authentication, and a limit on failed attempts. On WP Alpha, brute force protection is part of the firewall on every plan, so the limit is already in place; the password and the second factor are up to you.

What it means

A login attack, often called a brute force attack, is a program guessing usernames and passwords against your site’s login form at wp-login.php. A related trick called credential stuffing tries email and password pairs leaked from other websites, on the chance you reused them.

Bots also use xmlrpc.php, an older file WordPress keeps for remote publishing and some mobile apps. It accepts many login attempts inside one request, which lets a bot try a long list of passwords while only appearing to make a handful of requests.

Before guessing, bots collect usernames. WordPress gives them away through the author archive (adding ?author=1 to your address) and through the REST API’s users list, so hiding your username is not a defence on its own.

Even when every guess fails, a heavy attack consumes server resources and can make the site slow, which is often the first sign an owner notices.

Common causes

• Weak or reused passwords. A password that appears in a breach list will be tried within minutes of an attack starting.
• Obvious usernames. “admin”, the business name, or a username identical to the display name shown on posts.
• No second factor. Without two-factor authentication (a code from your phone as well as the password), a correct guess is all an attacker needs.
• Open xmlrpc.php. Left enabled by default, it multiplies how many guesses a bot can make.
• Too many administrators. Former staff, old agencies and “temporary” accounts each add a password that can be guessed.

How to fix it

1. Audit the user list. Users > All Users, filter by Administrator. Delete accounts for people who no longer need access (attribute their content to yourself when asked). Downgrade anyone who only writes content to Editor. (Same on any host.)
2. Retire “admin”. If your username is admin, create a new administrator with a different username, log in as that user, then delete the old one and attribute its content to the new account.
3. Set strong unique passwords. Users > Profile > Set New Password generates a long random one. Store it in a password manager, and never reuse a password between your site, your email and your console.
4. Turn on two-factor authentication. Install a plugin such as Two-Factor (maintained by WordPress contributors) or use the feature built into your security plugin, then under Users > Profile enrol an authenticator app for every administrator. Keep the backup codes somewhere safe.
5. Limit failed attempts in WordPress. If your host does not already do this, a plugin such as Limit Login Attempts Reloaded, or the brute force settings in Wordfence, locks an address out after a few failures.
6. Block xmlrpc.php if you do not need it. Jetpack and the WordPress mobile app need it; most sites do not. Add this to .htaccess in the site root using File Manager: <Files xmlrpc.php> Require all denied </Files>. Check the site and any connected apps still work afterwards.
7. Revoke unused application passwords. Users > Profile > Application Passwords lists tokens that let external services log in without the main password. Remove anything you do not recognise.
8. Add rate limiting at Cloudflare. If your site is behind Cloudflare, a rate limiting rule on the path /wp-login.php blocks an address after a set number of attempts per minute, and the managed WAF rules catch common attack patterns before they reach the server.
9. Keep an audit trail. A plugin such as WP Activity Log records logins and changes, so you can see if an attack ever succeeded.

On WP Alpha

Brute force protection is part of the WP Alpha firewall on every plan. Repeated failed logins from one address are blocked before they reach WordPress, so a guessing attack does not slow your site down or need a plugin to stop it.

A business grade web application firewall sits in front of every site and Cloudflare is in front of that. If the firewall ever catches you after a few mistyped passwords, support on 24/7 live chat can check what happened and whitelist your address. The two things the platform cannot do for you are choosing a strong password and turning on two-factor authentication; those take a few minutes and are worth doing today.