How to Stop Brute-Force Login Attacks on Your Website

If you look at the access logs of almost any site with a login page, you will see automated requests trying usernames and passwords. These brute-force attacks are constant and automated, run by bots that hit thousands of sites. Most fail, but they only need one weak password to succeed, and even the failures cost you server resources.

Brute force versus credential stuffing

• Brute force: the attacker guesses passwords for a known username, often starting with common choices such as "admin" and a list of frequently used passwords.
• Credential stuffing: the attacker takes email and password pairs leaked from other breached sites and tries them on yours, betting that people reuse passwords.
• Password spraying: one or two common passwords are tried across many accounts, to avoid lockouts.

The defence is similar in each case: make guessing slow or impossible, and make guessed or reused passwords useless.

Nine ways to shut down brute force

1. Use strong, unique passwords

This is the foundation. A long, random, unique password defeats brute force in practice, and uniqueness defeats credential stuffing. Use a password manager so nobody has to remember them. Our article on password policies covers this in more detail.

2. Add two-factor authentication

Even a correct password is not enough when a second factor is required. Enable 2FA for every administrator and editor account. It turns a leaked password from a disaster into a minor annoyance. See our article on two-factor authentication for site admins for how to choose between methods.

3. Limit login attempts

Allow a small number of failed attempts, then lock or delay further tries from that IP address or account for a period. On WordPress, a login-security plugin provides this. Be careful with account lockouts, since attackers can use them to lock real users out; lockouts per IP address combined with increasing delays are usually a better fit.

4. Do not use obvious usernames

• Do not use "admin" as the administrator username.
• Prevent username enumeration where you can. WordPress can reveal author usernames via author archives and the REST API, so limit those if you do not need them.
• Make the login error message generic, for example "Incorrect username or password", never saying which one was wrong.
• Give publicly visible author names a display name different from the login name.

5. Put a WAF or CDN in front of the login page

A web application firewall (often included with a CDN) can rate limit requests to login URLs, challenge suspicious clients and block known bad IP addresses before they touch your application. This protects server resources as well as accounts, because blocked requests never run PHP.

6. Add a challenge for bots

A CAPTCHA or similar challenge on login, registration and password reset forms stops many simple bots. Choose a privacy-conscious option and ensure it works for people who use assistive technologies.

7. Restrict who can reach the login page

• If only your team logs in, allow access to the admin area only from specific IP addresses or a VPN, using web server rules or firewall settings.
• Add HTTP basic authentication as an extra gate in front of the admin URL, so bots must pass that first.
• Moving the login URL to a custom path reduces noise in logs. It is not real security, since determined attackers can find it, but it cuts down on automated traffic.

8. Disable features you do not use

WordPress offers XML-RPC, which accepts login attempts and can allow many password guesses in a single request. If no application of yours needs it, disable it. Likewise disable unused user accounts and delete old ones.

9. Watch for signs of attack

1. Check your server access logs for repeated POST requests to wp-login.php or xmlrpc.php from the same or many addresses.
2. Turn on email alerts for new administrator accounts and for repeated failed logins.
3. Review the user list for unfamiliar accounts, especially with administrator roles.
4. Use a monitoring or audit-log plugin that records logins and changes.

What to do if an account was compromised

Change the password and revoke active sessions, enable two-factor authentication, scan for malware, review users and recently modified files, and rotate any other credentials stored on the site. Our incident response article outlines the full process.

Why it matters even when attacks fail

A failed brute-force attack still has costs. Every attempt on a WordPress login loads PHP and queries the database, so a bot sending several requests per second can slow the site for real visitors. Logs fill up, which hides genuine problems, and some attempts are probes that check whether your software has known weaknesses. So even if your passwords are strong, filtering this traffic early, at the firewall or CDN rather than in PHP, is worthwhile.

Finally, treat the login page as an entry point for every kind of user. Editors, shop managers, contractors and former staff all hold accounts. Remove accounts that are no longer needed, give each person the lowest role that lets them do their job, and require 2FA for the powerful roles. Fewer, more tightly controlled accounts mean fewer ways in.

Defence in layers

No single measure is enough, but combined they make your site an unattractive target: unique passwords, 2FA, rate limiting, a firewall and restricted access. Zebra Hosting Cloud runs Plesk on every plan, where you can manage protection settings, and our security page describes how we approach safety.