No One Is Trying To Brute Force Your WordPress Admin Password

When it comes to improving the security of the WordPress ecosystem one of the biggest problems we see is the shear amount misleading and often times false information that is put out by security companies. One of the most frequent falsehoods we see is the claim that there are a lot of attempts to brute force WordPress admin password. Not only is the claim false, but is so obviously false that these security companies either don’t understand the basics of security or they are knowingly lying to the public, either of which would be a good reason for you to avoid them.

To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:

  • 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
  • 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
  • 10 characters long: Over 839 quadrillion possible combinations  (839,299,365,868,340,224)
  • 12 characters long: Over 3 sextillion possible combinations  (3,226,266,762,397,899,821,056)

Now that you have an idea of the number of requests it would take to actually do a brute force attack, lets look at the number of attempts that security companies are claiming are occurring that support their claim that brute force attacks are going on.

First up is Wordfence, back in January they put out a post about the claim that brute force attacks are going on and gave a figure for how many login attempts had occurred over a recent 16 hour period (they call each login attempt an attack):

During this time we saw a total of 6,611,909 attacks targeting 72,532 individual websites. We saw attacks during this time from 8,941 unique IP addresses and the average number of attacks per victim website was 6.26.

The total during that time period likely isn’t any where near enough login attempts for even one brute attack to be successful, but with less 7 attempts per website, that clearly is not evidence of brute force attacks actually occurring.

How about Sucuri Security, they have a page on their website entitled WordPress Brute Force Attacks, that is supposed to present the “state of brute force attacks against WordPress sites”. The graph shown there includes failed login attempts for websites “protected” behind their website firewall. There is an obvious issue with that since failed login attempts are not necessarily malicious, so the graph is not necessarily entirely that accurate. Even with that caveat, the largest amount on one day looks to be have been about 50 million requests:


We don’t know how many websites that is split across, but even if it was one website that likely wouldn’t be nearly enough for one successful brute force attack per day.

In one instance recently, someone we perviously did some work for contacted us because they had gotten an email from Sucuri’s WordPress plugin that was alerting them to brute force attack. In that instance Sucuri was claiming that a brute force attack was occurring based on a total of 30 login attempts.

Security Companies That Don’t Understand the Basics of Security

Back in September of last year Sucuri not only claimed that brute force attacks where happening, but also claimed that brute force attacks are frequent source of hacking (despite the fact that they are not actually happening at at all):

However, brute force attacks are still going strong. In fact, they are one of the leading causes of website compromises.

So what could explain the false claims about brute force attacks?

One explanation is that these security companies don’t have an understanding of the basics of security, like knowing what a brute force attack is. Considering you don’t have to look at some obscure resource to know what they are, you just have to go to the Wikipedia, there isn’t any excuse for that.

The other explanation is that these security companies do know what a brute force attack actually is, but they are lying about them happening since if they told what was actually happening they wouldn’t be able to use it to push the products and services they provide. That would have the added bonus of allowing them to claim they can protect against something, without having to worry about that turning out to not be true (as we recently found with another claimed protection by Wordfence), since the brute force attacks are not actually happening.

Protecting Yourself From the Real Threat, Dictionary Attacks

So based on those security company’s data brute force attacks are not going on, but there are malicious login attempts happening, so what is actually happening? Based on looking at actual login attempts and the number of requests it looks like most of the malicious login attempts are from dictionary attacks.

A dictionary attack involves trying to log in using common passwords, think things like “123456” and “123admin”.

With dictionary attacks protecting your website is really easy, just use a strong password. Thats it. You don’t need to put in place all sorts of other protection, since the dictionary attacks will fail as long as you do that. WordPress now defaults to generating a strong password and displays a password strength indicator if someone chooses to create their own password, so if you have an Administrator choosing to use a weak password, you probably have bigger issues to worry about. If you are concerned about lower level users using weak passwords and then being subject to dictionary attacks, there are a number of options to enforce stronger passwords that are available.

With it being that easy to prevent what is going on, it would be difficult for security companies to promote products and services to deal with this, so that is why we wonder if they are intentionally lying about what is going on.

It also worth noting that there is likely a quite a bit of overlap between the passwords tried during different dictionary attacks, so the amount passwords tried is likely much less than the total attempts occurring over even a fairly short period of time.

Help Us Clear Things Up

If you see someone claiming that brute force attacks against WordPress admin accounts are happening, we would appreciate if you point them to this post, so that we can start to clear up the false information being pushed by those security companies and people can start focusing on properly protecting themselves.

7 thoughts on “No One Is Trying To Brute Force Your WordPress Admin Password”

  1. As someone that hosts many websites, I agree with you that brute forcing the login is going to amount to a waste of time on their part. But what it does still do is eat up server resources that should be spent elsewhere. So if I, as a host, can devote as little resources as possible to stopping failed login attempts then I am for it. So while I agree with you, I wouldn’t dismiss that it’s still a common occurrence to see a WordPress login being hit for a few days (to what amounts to a few hundred attempts) from time to time. But if it slows down your website during an important period, that’s still a no-go.

    1. As mentioned in the post, a brute force attack involves a lot more attempts than a few hundred, so what you are describing isn’t a brute force attack. We didn’t say there were not login attempts, just that they are not brute force attacks and explained why that distinction is important.

      If the website is being slowed down by a few hundred login requests there is something very wrong with the server.

  2. I get your distinction on brute force versus dictionary attack. But I think it’s rather semantics than a difference worth noting. You are assuming it’s a dictionary attack because of the short duration. But they could stop for any variety of reasons, you just picked one to suit your argument. In which case you’re no better than WordFence (which you like to harp on from time to time for the same exact thing). The end impact is still a lot login attempts on the server.

    I would also reserve judgement on what a server should and should not sustain. You don’t know the configuration or the resources available on said server. We don’t run high powered servers, we segregate our clients on smaller servers to avoid putting all our eggs in one basket. We also don’t host large sites, so the need for high powered servers is not cost effective. So if a couple hundred hits happen all at once and creates a lot of PHP processes, thus eating the ram up. Yes, it will make it run slow. It doesn’t mean something is very wrong, it just means the server isn’t built to handle irregular traffic like that. Software like modsec, csf/lfd and yes WordFence make this a rare occurrence but it does happen from time to time when the attacker jumps IPs often.

    Finally, while I do enjoy reading your blog (you are very knowledgable at what you do), managing sites as a host offers different experiences than fixing sites for folks. I don’t know if you are a host, can’t assume, but even from my short experience I can see the impact from these kinds of attack and it’s still worthwhile for me to find solutions to prevent them.

    1. The duration of the attack does not determine whether a set of malicious login attempts is a dictionary attack or a brute force attack, so we never brought up the duration of the attack. Instead we said that “it looks like most of the malicious login attempts are from dictionary attacks” “[b]ased on looking at actual login attempts and the number of requests”. So it is not the duration, but the number of login attempts and looking actual data on login attempts that leads us to believe that most attempts are part of dictionary attacks. That is separate from the fact that they are not brute force attacks, which is based on the number of login attempts being way to low to match that type attack. So while most malicious login attempts could be something other than dictionary attacks (though the evidence points towards that), they could not be brute force attacks.

      A few hundred login attempts and billions of login attempts are not similar at all, so the difference between dictionary attacks and brute force attacks is not just semantics just based on that (there are also other important differences, like of how you protect your website that we mentioned in the post).

      We stand behind our statement that if the website is being slowed down by a few hundred login requests there is something very wrong with the server. If you are over provisioning servers to that degree then that would in fact be a problem with the server and we would recommend that your customers find a better web host. Even in that case that doesn’t make what is going on brute force attacks.

  3. Thank you for this article and thank you for clearing things up for people like me, who are interested, but not at all experts (and in my case: nor even “well informed”).

    While I get everything you say, and after checking the websites of the two companies you have mentioned, one question still remains open to me: Where is the threshold of, say, login attempts, where I should start worrying that there is an actual attack (be it brute force, be it dictionary) going on?

    Or is this question practically irrelevant because this way of entering a site should be blocked on the server side (of a decent hosting company) anyway? I am thinking of fail2ban and similar software.

    1. There are actual attacks going on all the time, but they look to be made up mostly of dictionary attacks, which will not succeed if you are using a strong password. So for the average website all you need to do is to use a strong password and you can otherwise ignore the attacks.

Leave a Reply

Your email address will not be published.