Support

Project:Honeypot has not been a very effective solution for the past several years, but some people seem to be sentimentally attached to it, which is why the code is still there. I don't really recommend it for any practical purpose.

Moreover, the shape of the attack you are experiencing is one which can't be stopped or detected reliably – not without locking legitimate users out. As you said, the same IP only comes back after several hours. From the point of view of the server or even CloudFlare this does not look any different than a legitimate user trying with the wrong password, realising they have done something wrong, and going on a sidequest trying to find the correct login info. They come back hours later, oh snap, it's wrong again. The only way you could address that is blocking the IP for a few days the first time they enter the wrong username or password. But, of course, this would block legitimate users making a small typo as well.

Since you have CloudFlare and assuming everyone who needs access to the site is geographically close, you could create a rule to block all countries except Canada from any /wp-admin URL that's NOT /wp-admin/admin-ajax.php. Note that admin-ajax.php is called even from the frontend of the site (stupid, but it is what it is). This wouldn't stop the brute force attempts, but even a successful one would be limited to the frontend.

Beyond that, add 2FA with a third party plugin to all privileged accounts so that the attacks fail.

That's basically all you can do in WordPress. It does not separate frontend and backend access, really. It's all the same as far as it's concerned. This is atrocious for security. If you want to have proper security, you need a proper CMS with hard separation between administrator and frontend i.e. Joomla. In Joomla, Admin Tools can even block frontend login of Super User accounts for an additional layer of security. This is not possible in WordPress because, as I said, there is no separation between front- and backend login. In fact, this is why you can't block or put additional access controls to the WordPress backend: the login always takes place in the frontend (the /wp-login.php URL)!

Oof. That off-hand comment warrants a long reply.

What drives me nuts in WordPress is its idiotic insistence in password authentication being something you cannot disable for API access and, to a lesser degree, web access.

If you have the username and password of a privileged user, you have API access. If you have API access you can do all sorts of things, including changing the site in substantial ways, and install arbitrary code – which means you have pwned the site thoroughly.

This words regardless of 2FA (does not apply in the JSON API) and any protection measures / secondary access controls applied to wp-admin itself.

You cannot disable the API without breaking the Block Editor. At best, you can limit the active endpoints BUT the Block Editor still requires access to posts and pages, i.e. an attacker would still be able to inject malicious client-side code which can be used to launch a second stage attack to steal a login session and pwn the site thoroughly.

Even though newer versions of WordPress added support for Application Passwords for API authentication, the API password authentication is enabled by default and cannot be disabled.

This means that, ultimately, the security of any WordPress 5.0+ site relies exclusively on all users beyond the level of a regular user (who can only post comments) using strong, complex passwords. If you rely on people not screwing up, they will.

To be fair, Joomla wasn't much better before version 4.2. I had pointed that out since 2009. It took me 12 years to convince people that my ideas about hardening it are valid, and cost me being painted an arsehole. It was worth it, every miserable minute of it. You have WebAuthn. You can disable password authentication. The API uses secure tokens for authentication. The MFA uses a captive login which disables all functionality until you provide a valid second factor. All of it my code, my ideas, my pain and suffering over 12 long years. Core updates are signed as of October 2024. Also my idea, presented at J and Beyond 2017 (they did use a technically better solution, which wasn't available in 2017, though – and I am grateful for it!). If WordPress does the same, I won't see any reason to have any objections to using it. Get rid of passwords, make sure the alternatives are secure, and prevent core updates of questionable provenance to be installed. It's as simple as that.

People will of course counter that there are millions of sites and only a handful get hacked. That's a stupid argument. There are billions of cars ride every year, but only a few hundred thousand car crashes. This doesn't mean it can't happen to you. It doesn't mean you don't need seatbelts and airbags and crumple zones and active braking. Quite the opposite. There are millions of plane rides every year. A handful of fatal crashes. This doesn't mean you don't need redundant systems, crew CRM training, and air traffic controllers. Quite the opposite. The fact that something can go wrong is reason enough to ensure it doesn't and, if it does, the impact is as small as possible. It will never be perfect, but at least it's orders of magnitude better than sitting on our thumbs, lamenting on the dire state of affairs.

That's my two cents on the subject.

Cheers :)