How to Stop Brute Force Attacks on WordPress

Q: Does hiding the login URL really stop brute-force attacks?

It stops most of them. Automated bots target the default wp-login.php and wp-admin paths. When those return a not-found response and your real login lives at a custom address, the bots have nothing to attack. Combine it with 2FA and lockouts for full coverage.

A brute-force attack is the cheapest attack on the internet. An attacker points a botnet at your wp-login.php, feeds it a list of leaked passwords, and tries thousands of combinations until one works. It costs them almost nothing, and they run it against every WordPress site they can find, around the clock.

The defense is straightforward: make the login page hard to find, hard to guess, and impossible to flood. This guide shows how to do exactly that with the free WordSec plugin, using its Login Security module. Most of these steps take a couple of clicks each.

How brute-force attacks actually work

Before fixing it, it helps to know what you are up against. A typical campaign looks like this:

Bots discover your login URL, usually the default wp-login.php or wp-admin.
They harvest valid usernames through author archives and the REST API.
They submit password guesses at high speed, often from many IPs at once.
They also hit xmlrpc.php, where a single request can test many passwords at once.

Each of those steps has a countermeasure. Close them one by one and the attack collapses.

First, get the plugin in place:

In your WordPress admin, go to Plugins, Add Plugins and search for WordSec.
Click Install Now, then Activate.
Open the WordSec menu, click Get Key to activate your free license, then open the Login Security module.

Everything below lives inside that module.

If bots cannot find your login page, they cannot brute-force it. This one change removes you from most automated target lists.

In Login Security, enable Hide login URL and set a custom path, for example /my-secret-login. From then on, the default wp-login.php and wp-admin return a not-found response, and you sign in at your private address instead.

Hiding the login URL is the highest-impact, lowest-effort step on this list. The vast majority of brute-force traffic targets the default path and simply gives up when it disappears.

While you are here, also enable Hide login errors. Default WordPress messages tell an attacker whether the username or the password was wrong. A generic message gives them nothing to work with.

Step 3: Turn on two-factor authentication

Even a perfect password can leak in a breach somewhere else. Two-factor authentication (2FA) means a stolen password alone is useless, because the attacker also needs the second factor.

WordSec offers role-based two-factor authentication, so you can require it for administrators and editors while keeping things light for lower roles. Enable 2FA for your admin role first, scan the code with an authenticator app, and confirm. From that point, a brute-forced password cannot get anyone into an admin account.

A captcha stops automated scripts from submitting the login form at machine speed. WordSec supports three providers, reCAPTCHA, Cloudflare Turnstile, and hCaptcha, across up to five forms, including login, registration, and password reset.

Pick a provider, paste in your site keys, and enable the captcha on the login and registration forms. Turnstile is a good default if you want protection without making real users solve puzzles.

Step 5: Enable brute-force protection and honeypots

This is the layer that punishes persistence. WordSec brute-force protection locks out an IP after too many failed attempts, and honeypot traps catch bots that fill in hidden fields a human never would.

Enable both. Set a sensible failed-attempt threshold and lockout duration. Legitimate users almost never trip these limits, while bots hit them within seconds and get banned.

Step 6: Restrict access by IP, country, and time

Tighten the circle around who can even reach the login. In Login Security you can:

Whitelist IPs, CIDR ranges, or whole countries so only trusted networks can sign in.
Apply role-based login time restrictions, for example blocking admin logins outside business hours.
Add signup restrictions to limit who can register in the first place.

If your team only logs in from a known office or VPN, an IP whitelist alone removes the entire public attack surface.

Step 7: Enforce strong, unique passwords

Brute force only works when passwords are weak or reused. WordSec lets you enforce that they are neither:

Strong password enforcement rejects weak choices at the source.
A leaked-password check blocks passwords known to appear in public breach lists.
Reuse prevention stops users from cycling back to an old password.
A role-based password expiry policy rotates credentials on a schedule for sensitive roles.

Behind the scenes, WordSec stores credentials with Argon2 encryption and supports salt rotation, so even a database breach does not hand over usable passwords.

Step 8: Close the xmlrpc.php side door

xmlrpc.php lets an attacker test many passwords in a single request, which makes brute force far more efficient. Unless you specifically rely on it, turn it off. WordSec includes a one-click hardening toggle to disable XML-RPC, along with toggles to block user enumeration so bots cannot harvest your usernames in the first place. You can read more about the firewall and hardening layer in How to Set Up a WordPress Firewall and Block Bad Traffic.

Finally, keep an eye on what is hitting you. WordSec keeps detailed login attempt logs, so you can confirm the attacks are being blocked and spot any new pattern early. Pair this with the Live Traffic monitor to see attempts in real time.

A quick recap

To stop brute-force attacks on WordPress:

Hide the login URL and hide login errors.
Require two-factor authentication for admins.
Add a captcha to login and registration.
Enable brute-force lockouts and honeypots.
Restrict logins by IP, country, and time.
Enforce strong, unique, non-leaked passwords.
Disable XML-RPC and user enumeration.
Monitor login logs and live traffic.

WordSec does all of this from a single dashboard, and the Free plan already includes brute-force protection and two-factor authentication.

Frequently asked questions

It stops most of them. Automated bots target the default wp-login.php and wp-admin paths. When those return a not-found response and your real login lives at a custom address, the bots have nothing to attack. Combine it with 2FA and lockouts for full coverage.

Will two-factor authentication lock me out?

No, as long as you keep your authenticator app or recovery method available. WordSec lets you enable 2FA per role, so you can roll it out to admins first and confirm your own setup before requiring it more widely.

What is the difference between brute force and a dictionary attack?

A pure brute-force attack tries every possible combination, while a dictionary attack tries known and leaked passwords first because they are far more likely to work. WordSec defends against both: lockouts stop the volume, and the leaked-password check blocks the credentials dictionary attacks rely on.

Is brute-force protection available on the free plan?

Yes. WordSec includes brute-force protection and two-factor authentication on the Free plan. Premium and Business add more advanced login controls such as additional captcha placements and scheduled salt rotation.

Should I disable xmlrpc.php?

For most sites, yes. Few modern setups need it, and it enables an efficient multi-password brute-force technique. WordSec disables it with a single hardening toggle, and you can re-enable it if a specific integration requires it.

Lock down your login in minutes: install WordSec, then follow the full security guide to put every other layer in place.