Support » Requests and Feedback » Built-in brute force protection

Viewing 6 replies - 1 through 6 (of 6 total)
  • Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    Currently, by default, WordPress has no credential brute force protection for the “wp-login.php” and “xmlrpc.php” scripts.

    True.

    Wouldn’t it be easy to solve this whole issue by just implementing anti brute force protection into WordPress itself, instead of using all kind of 3rd party measures which not everybody uses?

    I don’t think it’s that easy exactly. 😉

    An easy solution would just temporarily preventing login from IP X for X seconds/minutes after X login attempts within X minutes.
    As an extra measurement for “wp-login.php” you could also add strong re(CAPTCHA) support, which makes it much harder to write automated brute force bots.

    I don’t think it’s a bad idea though and other login mechanisms like your ssh access do that today.

    The problem I see with that IP grey listing is it really needs some sort of understanding from the user managing their site. They could easily be timed out of their site because of password issues.

    CAPTCHA don’t really work (there’s too many cheap ways to get around them for bad guys and they do) and they discriminate against accessibility users. Also generating a good CAPTCHA would require more dependencies such as PHP graphic libraries that not all hosting has by default.

    Yes, we use Google CAPTCHAS here for new registration and yes, we’re ashamed. It’s dependent on a third party system and that’s not really something you want to build in.

    Effective brute force mitigation really needs something outside of your installation and here’s why: you want to get the intelligence from other users. That’s why plugins such as Jetpack are so effective. When your site is attacked and the attackers IP is in the Jetpack protect database then your site rejects that IP. When someone attacks your site and they’re not in the database then your site is helping the next IP.

    Also Jetpack will reject that IP as well. Community data gathering is cool.

    Thank you for the response!

    Instead of “easy” it should have said “better” 🙂

    I totally agree with you that additional solutions like Jetpack are great. The problem is, you and I know this, but it’s not the default and thus many people will not opt to install these. The whole point is that by default WordPress is not protected and those sites are part of the security problem of the web.

    I also agree with you that CAPTCHA and IP grey listing are not the perfect solutions, but now there’s no solution by default at all 🙂
    Those were also merely suggestions, there are probably much better solutions everybody involved with WordPress development could think of together.

    Something like adding small delays on login attempts would greatly improve protection already. For example, IP 123.123.123.123 tries to login 5 times within a 1 minute timeframe, it would get blocked for 1 minute. After which the user can try again.
    This wouldn’t have too much of an impact on legit users trying to login and doesn’t totally lock them out.
    This however would help making automated brute force bots way slower, as they are not able to continuously hammer the wp-login.php/xmlrpc.php, but are restricted to that same 1 minute timeframe with only 5 login attempts.

    People, including me, have been asking for this for years.

    The last time I think the arguments against were ‘install a plugin’ – but we know that millions of people don’t even enable the anti-spam plugin that’s bundled with WP and end up spammed – and ‘we don’t want to lock out people who can’t remember / get their browser or password manager to remember their password’.

    But it is a disgrace that in 2017 an out of the box installation will allow an attacker as many login attempts as they want, as fast as they want, without doing anything about it or even notifying the owner that it’s happening.

    (Oh, unless you use a mobile app to update your site(s), install a plugin to disable xmlrpc. If you must use JetPack, one of those plugins whitelists IP addresses used by it.)

    Brute forcing isn’t 5 requests a minute. That would take tens of thousands of years unless you strike lucky. Enforcing strong passwords for admins by default would be a good start.

    Locking IP is limited as brute force uses millions of IPs but only about 100 requests per IP per 24 hours. At least that’s what the Feb 2017 Wordfence reports say.

    So locking by IP you’d need a central set of servers that track all failed logins by IP across all WordPress sites. That’d need a significant investment in infrastructure. That costs money and how many would be prepared to pay for that? Who would manage that infrastructure? How many companies would be happy that their servers need to talk to external servers for every failed login? They can’t just lock down their server firewalls. Free and open source is the main reason WordPress has the share it does.

    Besides if an admin isn’t bothered about security they are probably not bothered about keeping Linux, PHP, or WordPress up to date. So any updates to address this may be mute.

    • This reply was modified 2 years, 7 months ago by  Pwhitehurst.
    • This reply was modified 2 years, 7 months ago by  Pwhitehurst.
    • This reply was modified 2 years, 7 months ago by  Pwhitehurst.

    Yes, ensuring strong passwords would help, but basically this is excuses and those were not good enough a decade ago.

    You can have a centralised system – one of the first scripts to stop bots trying to bruteforce SSH logins had the option to share IP addresses that it had banned on your server and get the ones that other people had banned. I can’t remember just how it did it, but it wasn’t particularly problematic at the time (now, half the work is stopping it being gamed by the baddies).

    But you don’t need to have a centralised system. Yes, that will allow some networks to use multiple IP addresses more easily, but looking at the logs for about sixty sites, I do not see one million attempts each from one IP address to get to wp-login, I see far fewer IP addresses, most of which are making multiple attempts in a couple of seconds before something on the server bans them.

    However the ability to do that is limited to those who can run something like fail2ban on the server their WP runs on.

    Besides if an admin isn’t bothered about security they are probably not bothered about keeping Linux, PHP, or WordPress up to date

    I suspect most users don’t get a say in the first two (and, finally, WP now makes an attempt to keep itself up to date).

    As in the days when WP insisted you have an admin user called ‘Admin’, why should they expect what WP does to be wrong?

    I’ve just looked at https://wordpress.org/about/stats/

    When fewer than half of the live installs are running any version of 4.7, no-one should be able to say ‘get users to install a plugin to solve this security problem’ with a straight face.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Built-in brute force protection’ is closed to new replies.