Add some basic brute force protection please

[discobot]

I would like to see some basic protection against brute force attacks on the wp-login.php and xmlrpc.php. At the moment, you will need to add plugins and/or disable access to xmlrpc.php using plugins. I hope to see ClassicPress with a basic protection like a captcha on the login page.

---

Read-only archive: https://petitions.classicpress.net/posts/37/add-some-basic-brute-force-protection-please

Author: Rudy Brinkman

Vote count: 48

Status: Declined

Tags:

• request-add-feature

---

Comments

Please: no captchas!

~ posted by KTS915

I have to agree, I don’t like captchas… # of retry attempts may be better

~ posted by Wade Striebel

I am in favor of number of failed attempts and maybe account locking

~ posted by David Shanske

Definitely no captchas! Why make it a problem of the user?

~ posted by Pieter Bos

It is embarrassing that you there is no limit to how many failed login attempts you can make on a default WP installation without it complaining / doing something about it. I add the protection at the server level, but it really should be more secure ‘out of the box’.

No captchas though, just rate-limiting.

~ posted by Ian

+1 on rate limiting, no captchas

~ posted by Pedro de Carvalho

Would be a good idea to collate all security functionalities into one Security submenu in the Settings menu, as with this petition: https://petitions.classicpress.net/posts/136/new-settings-submenu-security

~ posted by Raymund

I implement brute force protection using transients, which simply lock someone out of their account for a fixed period of time after a certain number of failed attempts. After that time has elapsed and they have logged in successfully, the transient is deleted. Simple.

But I have hard-coded it. Would need to add a UI before it could be added to core.

~ posted by Tim Kaye

Brute force protection at server level is the more useful option. Application level protection implementations are still vulnerable to triggered DDoS from brute force attempts.

~ posted by William Patton

Also agree with rate limiting, no captchas

~ posted by Alan Coggins

Brute force protection at server level is the more useful option. Application level protection implementations are still vulnerable to triggered DDoS from brute force attempts.

Agree, this is best done at the server level using fail2ban or similar.

There is also https://wp-fail2ban.com/ which provides specific integration with WP/ClassicPress.

~ posted by James Nylen

This is a bad idea to include in Core, and is an example of overstepping. Firstly, there are a million use cases for a CMS like ClassicPress and preventing certain login behaviors will inhibit (for example) testing, etc. Certain things can and must remain the responsibly of layers “higher up” the stack such as server configuration and firewalls. The WordPress world is notorious for overloading the PHP layer with things it shouldn’t be responsible for… this is one of those things.

There are also marketing concerns: for every feature that ClassicPress adds to Core, the more it chips away at building an ecosystem.

~ posted by Jesse

Noooo! Captchas are terrible for usability and accessibility. By all means do rate-limiting but don’t destroy usability for legitimate users as a way of trying to put off bad users.

~ posted by zigpress

[Code_Potent]

@discobot

I would like to see some basic protection against brute force attacks on the wp-login.php and xmlrpc.php. At the moment, you will need to add plugins and/or disable access to xmlrpc.php using plugins. I hope to see ClassicPress with a basic protection like a captcha on the login page.

For Apache servers, it only takes a few lines in .htaccess to do what you’re asking. I’m sure nginx has counterpart directives if you’re on that server. These directives kick in before ClassicPress is loaded.

# A message for those denied access.
ErrorDocument 401 "Denied"

# To password-protect the login/admin.
<Files wp-login.php>
AuthType Basic
AuthName "Secure Area"
AuthUserFile "/home/path/to/your/.htpasswd"
require valid-user
</Files>

# To prevent access to xmlrpc.php.
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

One and done. If you don’t get past the server’s user/pass prompt, ClassicPress isn’t even loaded. If you do pass the prompt, then you get the normal login page where you can then login as usual.

[1stepforward]

I agree with @Code_Potent’s approach. I’m a great believer in implementing as many server-side security measures as is reasonably practicable, thus preventing access to CP completely when necessary. The only caveat is that access to the file system is required, although this is not usually a problem for files such as .htaccess and .htpasswd.

And while plugins such as Wordfence and Shield offer useful extra protection and peace of mind, they should be considered a last line of defence imho.

[viktor]

It is very unlikely that this would be implemented in the core for a few reasons:

1. XML-RPC will eventually move to a core plugin
2. Rate limiting is best handled by the servers
3. There is a brute force plugin available in the directory
4. No one likes captchas

This petition will auto-close in a few days. If anyone feels differently, please share your thoughts to keep the petition open.