Failed logins can happen for a variety of reasons. Often, it is simply the result of a user who has genuinely forgotten their password. It happens to the best of us so that we won’t judge too harshly. Sometimes, however, something more serious might be happening – someone is trying to break in.
The art of troubleshooting failed logins
Like all other WordPress issues, troubleshooting (aka getting to the bottom of things) is the first step we need to undertake. This will help us make sure we are dealing with the actual issue and not its symptom. Fortunately, there is an easy way to start this process – look at the data. Essentially, you should see one of two things:
- Wrong username and wrong password combinations
Wrong username and password combinations can happen for one of two reasons. Either someone or something is trying to guess a username/password combination to gain access, or it’s a targeted attack. In the case of the first option, this is a pretty common occurrence. Else, it might be a targeted attack on your website either to gain access or overload your website (DoS/DDoS).
- Right username and wrong password combinations
Right username and wrong password combinations can mean one of two things. Either it’s a genuine case of someone forgetting their password, or someone has discovered an actual username registered on your WordPress and is now trying to guess the password.
One other thing that you should remember to look at is the frequency. A large number of attempts in a short period is usually the sign of an automated attack. On the other hand, a slow and irregular timeline is a tell-tale sign of a person who hasn’t had their coffee yet.
The perils of too many failed login attempt
Password-guessing attacks are quite prevalent. Too many failed WordPress login attempts are generally indicative of these kinds of attacks. Without a way to manage this, you could be leaving your site open to attacks and disruptions. Fortunately, managing this risk is very easy and requires little administrative effort.
WordPress does not offer any functionality to limit or take evasive actions when there are failed login attempts. A user can keep trying ad nauseam until they get it right. While giving people extra chances can be argued to be the ethical thing to do, imposing limits and controls can go a long way in ensuring the security and integrity of your WordPress website.
How to prevent failed login attempts on WordPress
Implementing a WordPress failed logins policy is easier than it might sound, thanks to MelaPress Login Security. This plugin offers administrators a proverbial swiss knife for implementing good governance and solid login security, including a failed logins policy.
You can easily choose the number of failed logins a user trying to log in needs to accumulate before action is triggered, giving you complete control over how strict or lenient you want to be. Once the threshold is triggered, you can choose whether the account will be automatically unlocked after a predetermined amount of time passes or whether it will require manual intervention by an administrator. You can also choose whether the user will need to reset their password or not.
Other things to consider
One other option worth mentioning is CAPTCHA. Plugins such as CAPTCHA 4WP are great at helping you stop automated attacks. Since a CAPTCHA needs to be completed before a logging attempt is made, bots behind such attacks fail the test and will not make a single login attempt.
Another option that tends to come up in conversations about failed login policies is that of blocking IPs. Through this option, the offending IP is blacklisted, preventing it from accessing your website in the first place. While this is technically correct, a persistent malicious actor can simply use a different IP – which they can do with ease. Because of this, the strategy of blocking IPs often ends up being a cat and mouse game.
One better option is to use a CDN (Content Delivery Network) and let them deal with blocking offending IPs. This can save you precious time, which you can invest in productive things.
How to design a WordPress failed login policy
Before we begin to enforce a failed login policy on a WordPress website, there are a few things that we need to think about. Like all other security-related issues, managing failed login attempts suffers from the security/usability paradox. The more secure something is, the less usable it becomes. The reverse is equally true. Not allowing anyone to log in is very secure but hardly usable. Giving users unlimited chances at logging can compromise security but increases usability.
What you need to understand is how much leeway you are willing to give your users. Traditionally, three attempts are viewed as both adequate and reasonable. Some disagree with this notion and place the maximum allowable login attempts at ten. Either way, offering unlimited login attempts is not a good strategy and can have negative repercussions.
The truth of the matter is that there is no right or wrong answer. Three is a safe number, but it will increase administrative overhead. Ten might have lower administrative overheads but carries more risk.
As such, you might want to start with limiting the number of login attempts to three and then assess the situation. When using MelaPress Login Security, it’s very easy to change this number. As such, you can very easily adapt the policy to your users and circumstances.
It would be best if you also thought about what happens when an account gets locked. Should the account unlock automatically after a pre-configured time window, or should an administrator unlock it manually? This question succumbs to the same problem as before: you need to decide between usability and security. Another essential aspect that might influence this part of the policy is the location of your users. If people are logging in from the other side of the world, are you happy to wake up at two in the morning to unlock an account? And if not, how long should a user wait before they can log in again? Will this impact their productivity or your bottom line?
Choosing the right plugins (and policy) to manage WordPress failed logins
Once you understand what you would like your password and failed logins policy to look like, you need to start working on the implementation. We previously mentioned MelaPress Login Security as a prime candidate. It offers many configuration options, allowing you considerable leeway when configuring and implementing your password policy.
Once you enable the failed logins policy for WordPress, you can choose how many attempts users have before their account is locked. You can also decide how it’s unlocked and whether you want to force users to change their passwords or not, as explained below.
Step 1: Install and activate MelaPress Login Security
Installing MelaPress Login Security is easy. You can download MelaPress Login Security plugin and then upload it to your WordPress website.
Once you install the plugin, click on Plugins from the WordPress side menu, locate the plugin, and click on Activate. This will add a new menu option called Password Policies, which you need to click on.
Step 2: Enable the Failed Logins Policy
Tick the checkbox next to Enable Failed Logins Policies to limit failed login attempts on your WordPress website. Enter the Number of failed login attempts before locking a user, with 3 – 5 generally considered a good start.
Other configuration options include what happens once an account is locked and whether blocked users are required to reset their password on unblock. Refer to the WordPress failed logins policy knowledge-base article for more information.
Step 3: Take additional security measures
CAPTCHA
We also touched upon CAPTCHA – the ubiquitous test present in many logins and forms that is designed to let humans pass while stopping bots and other forms of automated attacks. Plugins such as CAPTCHA 4WP make implementing such tests super easy while offering universal compatibility and support for different versions.
Two-factor authentication
In increasing the security of login processes, two-factor authentication is a must-have. Through this process, users need to authenticate a second time by entering a one-time passcode provided through their smartphone. By employing 2FA, which you can easily do through plugins such as WP 2FA, you can ensure that even if passwords get compromised, unless the person has the phone tied to that user account, they will not be able to log in.
Step 4: Going a step further (Optional)
With the password and failed login policies, CAPTCHA, and two-factor authentication in place, you should be well covered.
However, if your website still experiences large volumes of failed login attempts, you should consider using a CDN service. You might want to speak to your web hosting provider to assist you with implementing a solution suitable for large-scale attacks.
WordPress password security requires a 360 approach
As we saw throughout the article, several factors need to be considered when implementing a password policy. While blocking failed WordPress logins is a good first step (and a necessary one at that), by taking a 360 approach, you can be that much safer. Not only does this help you cover all of your bases, but it can also help you inspire more trust and confidence in your WordPress website.
A 360-degree approach looks at several factors, including plugins and themes, hosting, TLS, WordPress core, and others. This way, you can ensure that your WordPress security is in tip-top shape.
12 comments
Basically if you have a strong password (at least 15 characters long), and change it once a year, you should be fine. I get hundreds of failed login attempts every day, so I just change my password often and don’t even look at the audit trail anymore…
Very good point John. Indeed, if you use a strong password and 2FA you should be sorted. But you would still need to review the activity logs from time to time, just ignore the failed logins 🙂
Not good, not good.
-Even though failed WordPress logins bear no security risks, in response to this statement, no that absolutely incorrect. You have to realize that every failed login attempt is one step closer for an attacker achieving a successful brute force attack. The times they can get to try different passwords the better change an attacker has.
Should I block offending IP addresses – yes absolutely you should block offending IP addresses for a pre-determined amount of time if not permanently. If hacker is having to change their IP address constantly it will make your site less appealing for a hacker to put in effort compared to a site that does not block IP addresses.
Also you should be logging IP addresses for repeat offenders. Display an onscreen message informing them that their IP address has been logged. Use it as a deterrent. Report it to the relevant authorities and their internet service provider if known.
Also if hackers are using a particular username to try brute force attack access then block that account from accessing your site for let’s say 20 minutes every time they fail to log in 5 times in a row. Track number of failed login in attempts per username. Again if a Hacker is only able to try 5 passwords every 20 minutes it will act as a deterrent. Hackers want to be using thousands of passwords per hour to make an effective brute force attack.
-Avoid using common usernames such as admin, root, or your first name, in response to this statement you should be aware that if you make blog posts with your account on your wordpress website anyone can get your username. So if you are making blog posts you should be doing it with an account that has very limited permissions, that way if that account does get hacked damage limitation will be in place. You don’t want you account with admin privileges getting hacked. Don’t blog post with a high level account it takes about 2 seconds just by reading through the page code in the browser it will not matter what you changed your username to.
Also plugins are not good for security, they are one of the biggest vulnerabilities on wordpress. Plugins contain code that you did not write. Plugins can contain vulnerable code. If you use plugins you are completely relent on the plugin owner/developer to ensure that the plugin code is kept up to date and that there are no new security issues with their code. The less plugins the better.
Protect your data and protect your website members/users data. Restrict file and folder access as much as possible. If a user does not need access to certain directories on your server then restrict access. Log onto your server and check what permissions you have set for the various directories and files on your server. Start by making sure that users don’t have access to your wp-config.php file, it contains your database username and password. You don’t want people being able to log into your database, or they will have access to every single user account on your website including yours. I’m probably gone a bit off script here but you get the idea.
Website security is a layered approach, you should not be relying on a single fail point i.e. just use a strong password and you are good. Don’t be an idiot.
Thank you for your comment Mike.
I do agree with you that one should not use common usernames (such as admin and root), however, blocking IP addresses and doing all that work (like keeping a record of repeating offenders) is like playing a never ending cat and mouse game. Unless your website is targeted by a large scale brute force attack, you should not go down that route.
Also, saying that the plugins “are one of the biggest vulnerabilities in WordPress” and that they “contain code that they did not right” is untrue, very misleading and sensationalism. Quite frankly, all of the software you use to host your website (the Apache web server, the operating system it is running on, the countless services that make up the web server) and WordPress itself were not written by you.
We should try to be more constructive and realistic when talking about security etc. Pointing fingers and saying “everything is wrong / bad / insecure” is counter productive and won’t lead us forward.
My 2c.
@Robert Abela
I didn’t say “everything is wrong / bad / insecure”. Instead I actually gave specific examples of insecurities and advice for how to avoid those specific insecurities as I felt there was some mis-information on the page.
You state that because WordPress and Apache software is considered secure we should also consider wordpress plugins secure. They are not the same, the difference is WordPress and Apache software is well established and has been tried and tested on millions of installations over many many years. Where as wordpress plugins are not by default, for example a guy with 2 weeks coding experience could create a wordpress plugin riddled with security issues and publish it for anyone to download and install. This coupled with the fact that a plugin might not get necessary updates is why wordpress plugins are one of the biggest security risks. Sure there are many great wordpress plugins out there that have well written code but there are also many security vulnerable plugins. Because WordPress and Apache software is secure does not mean that a wordpress plugin is secure.
I do not agree that it is a cat and mouse game with regards to blocking IP addresses, if you not problematically blocking then you are allowing hackers to execute brute force attacks or denial of service attacks. One hacker could guess thousands of login passwords in a single day. I would be taking the logic that if an IP address has 50 failed login attempts in a single day that they should be banned as they are clearly not genuine, as a genuine user would have used the ‘forgot password’ mechanism after a few failed attempts.
Netflix and Amazon Prime block certain IP addresses also on their platforms for licencing purposes, they don’t see it as a cat and mouse game. Please explain your logic as to why you are advising people not to block IP address ?
Thanks for your response @Mike.
1) I never said that because WordPress and Apache are considered secure we should also consider WordPress plugins secure. I said that saying (quoting you) “Also plugins are not good for security, they are one of the biggest vulnerabilities on wordpress. Plugins contain code that you did not write.” is very misleading. The world is not black and white, but there are many shades of colours in between. And the same applies here, like in everything else. So we could be more accurate by saying “There are many good and well maintained plugins, but there are also many unmaintained and potentially vulnerable plugins. So not to jeopardize the security of your website always use a well maintained, reliable plugin.”
2) Comparing a WordPress website (of any size) to Netflix and Amazon is like comparing oranges to apples. Most WordPress site owners do not have the same resources and infrastructure to do that. And someone abusing a license (resulting in loss of money) is different than an IP generating failed logins. The same to what I said in regards to plugins applies here, there is no good or bad here. Trying to keep a record of offending IPs is a cat and mouse game. However, if you do notice that some IPs are in fact generating a high number of failed logins, then speak to the web host and they will take care of it. Addressing this problem at WordPress level is very inefficient. It is time consuming and resource hungry.
I agree with Mike. If you are getting repeated login attempts then you should block the IP addresses and report the issue to the ISP concerned. The reason you should do this is, as Mike suggests, because this is just a symptom of a bigger attack. Although you might only get a few attempts from a particular IP (typically I am seeing three at a time), these aggregate over time (where the same IP address does the same thing, over an extended period of time) and between different IP addresses.
So, multiple attempts from multiple IP addresses add-up to a distributed brute-force attack over time.
Robert says you don’t want to spend the time tracking all those IP addresses and individually banning them. But you don’t have to. Use an automated process to block the bot at the device’s firewall. For example, using fail2ban to scan your server logs will automatically ban IP addresses (after a certain number of attempts – which you can set) for a period you can determine, and report the incident to the ISP.
I am not saying one should not report any IP addresses at all. The way these things should be dealt with is on a case by case basis. My point was that you will always get a handful of failed logins on a daily basis on your site, and the more popular it becomes, the more you will get. It is not worth trying to block the IP addresses that generate such a small amount of failed logins. However, one should use a sort of online CDN / firewall service that helps in mitigating this issue.
I have a question.
Since my sites were all killed a week ago. After the backup. I changed all their passwords to longer more complex and randomized character strings.
But not only that, I also upped the site’s security, with firewalls.
And then I did something else.
I had an epiphany (or so I think), and since I access my sites via a Cpanel (don’t use the login page on each side), I decided to hide the actual wp-login.php files under another name and replaced them on each side with a fake one, that has every link changed to “#”, including the “Log in” button.
So a bot accessing /wp-admin will get sent to that fake page, and then, NOTHING should happen.
Nevertheless, I have started getting failed login attempts warning from one of the plugins I have installed on those sites (Limit Login Attempts Reloaded).
My question is, or rather are:
How is that even possible???
Can bots actually find the correct file even if it has a different name?
Should I try deleting the files completely?
Is there a possibility that the actual “attacks” are generated by a company that wants to scare me into getting their “premium” security plugin version?
I’m very confused and paranoid now.
Thanks for any feedback on this (btw, I’m not a technical guy, rather a basic WordPress user).
Thank you for your comment Oscar. I would definitely eliminate the probability that a security company is generating such attacks. There are many other easier ways how to promote products, that is too much of a hassle!
I do not know how you “replaced the wp-login.php file” but you cannot simply rename the file. You should use a plugin to do that. Alternatively, you can also add HTTP authentication in front of your WordPress login page. This is practical if you have a very small team of people. It’s like adding an additional layer of authentication in front of your WordPress login page. I hope that helps.
I have installed a plugin called login attempts, and also installed sucuri and they are showing me every day 8 thousand login attempts are going on my website. I am I want to know if there is any option to stop this.
Hi Prince,
Thanks for reaching out!
The first thing you should check is if the failed login attempts are happening on an existing user account. If that’s the case, you should make sure that the users are using strong passwords and have 2FA enabled.
If the failed logins attempts are coming through randomly (using generic / non-existent usernames) I wouldn’t worry much about them.
In case the attempts are too many, and they start affecting the performance of your website, you can try blocking the IP addresses in order to reduce the volume. However, you should note that the attackers can easily change their IP, meaning that they can easily bypass the blocking. In this case, the best thing you can do is to talk to your web host.
I hope the above information is of assistance to you.
Best wishes,
Rado