A Brute Force Attack consists of a large amount of repeated attempts at guessing your username and password to gain access to your WordPress admin. These attacks are automated, and the usernames and passwords used for guessing typically originate from big data leaks. Limiting the amount of login attempts that your site allows and blocking users who try an invalid username are two ways of protecting yourself against this type of attack. See full options below.
The Brute Force Protection options are located under Firewall Options.
Enable brute force protection
This option is a global enable-disable switch for all the items that appear under the heading Brute Force Protection. These include:
Lock out after how many login failures
This will lock out an IP address for a specified amount of time if that visitor generates the specified number of login failures. Note that it is common for real users to forget their passwords and generate up to 5 or more login attempts while trying to remember their username and/or password. So we recommend you set this to 20 which gives real users plenty of opportunity to sign in, but will block a brute force attack after 20 attempts.
Lock out after how many forgot password attempts
This limits the number of times the “Forgot password?” form can be used. This protects you against having your “Forgot password?” form used to flood a real user with password reset emails, and prevents attackers trying to guess user accounts on your system. Setting this to 5 should be sufficient for most sites.
Count failures over what time period
This specifies the time frame over which we count failures . So if you specify 5 minutes and 20 failures, then if someone fails to sign in 20 times during a 5-minute period, they will be locked out from login. Brute force attacks usually send one login attempt every few seconds. So if you have set the number of login failures to 20, then 5 minutes is plenty of time to catch a brute force hack attempt. You do have the option to set it higher.
Amount of time a user is locked out
This specifies how long an IP address is locked out for when Wordfence brute force protection locks them out. Remember, the goal is to prevent a remote attack from having many opportunities to guess your website’s usernames and passwords. If you have reasonably strong passwords, then it will take thousands of guesses to guess your password correctly.
So if you have your failure count set to 20, your time period set to 5 minutes and you set this option to 5 minutes, then an attacker will only get 20 guesses every 5 minutes and then they have to wait 5 minutes while they’re locked out. So the effect is that they only get 20 guesses every 10 minutes or 2880 guesses per day, assuming they realize that they can restart their attack exactly 5 minutes after being locked out. If you feel this is not long enough, then you can increase the lock-out time to 60 minutes, which drastically reduces the number of daily attempts at guesses an attacker has.
Immediately lock out invalid usernames
This option will immediately lock out someone who attempts to log in with an invalid username. Please note that your real users may mistype their usernames. This will cause them to get locked out, which is an inconvenience. We recommend enabling this feature for sites that have a low number of users such as 1-2 admins and/or a possibly a few editors. If a legitimate user is locked out you can find and delete any currently active block on the Wordfence Firewall > Blocking page.
Immediately block the IP of users who try to sign in as these usernames
Any username you add here will cause an IP to be blocked if they try to log in with that username. You can add usernames that are frequently used in brute force attempts such as “admin” or your domain name without the top domain. Make sure that the usernames you add to this list are not identical or similar to real usernames on your system since this could cause legitimate users to get blocked if they make a typo.
Prevent the use of passwords leaked in data breaches
This option prevents users from logging in with a password that exists on a list of passwords leaked in data breaches. Attackers use such lists to break into sites and install malicious code. You can choose to only block admins who use such passwords, or you can choose to let this option apply to all users who have the “publish posts” privilege (that includes admins). The default setting is to only block admins.
What is a password leaked in a data breach? When big sites are hacked, credentials are sometimes leaked. These leaks are used to compile lists of passwords. The lists are used by malicious actors who run bots and try to log in to WordPress websites. You can read more about this on our blog.
If you or another user is blocked by this option, you can regain access to your site by resetting your password. When you reset your password or change it within WordPress, this feature will also check the new password against the same leaked password lists. If you need to allow insecure passwords on your site for some reason, you can choose to disable this feature altogether.
Enforce strong passwords
You can use this to either “Force admins and publishers” or “force all members” to use strong passwords. We recommend you force admins and publishers to use strong passwords. When a user on your WordPress site changes their password, Wordfence will check the password against an algorithm to make sure it is strong enough to give you a good level of protection. If the password fails this check then it’s rejected and the user must enter a stronger password.
Wordfence checks that the password is a minimum length, that it doesn’t match any known obvious passwords and it then uses a point system to allocate points based on things like whether it contains a number, if it has upper and lower case letters and so on. If the point score does not exceed a required level, then it will reject the password the user entered.
Don’t let WordPress reveal valid users in login errors
By default, when you enter a valid username with an incorrect password, WordPress will tell you that you entered a good username but the password is wrong. If you enter a bad username and bad password, WordPress will tell you that the username does not exist. This is a serious security problem because it lets users easily find out which users exist on your WordPress site and target those for attacks.
This option gives a generic message of: “The username or password you entered is incorrect.” thereby protecting your usernames and not revealing if the hacker guessed a valid user. It’s strongly recommended that you enable this feature. We strongly recommend you enable this option.
Prevent users registering ‘admin’ username if it doesn’t exist
If you disable and remove the ‘admin’ account in WordPress and you have the option “Anyone can register” enabled in WordPress “General” settings next to “membership,” then it is possible for users to register an account with the username “admin,” which can cause confusion on your system and may allow those users to persuade other users of your system to disclose sensitive data.
Enabling this feature prevents the above from happening. We recommend you enable this option.
Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, and the WordPress REST API
On a WordPress system, it’s possible to discover valid usernames by visiting a specially crafted URL that looks like one of these:
Enabling this option prevents hackers from being able to discover usernames using these methods. This includes finding the author in the post data provided publicly by the oEmbed API and the WordPress REST API “users” URL that was introduced in WordPress 4.7. Note that some themes can leak usernames and we can’t prevent username discovery when a theme does this. We recommend that you keep this option enabled. For information on how to safely fetch a list of users posts to display, see Safely fetch a list of users posts.
Block IPs who send POST requests with blank User-Agent and Referer
Many badly written brute force hacking scripts send login attempts and comment spam attempts using a blank user agent (in other words, they don’t specify which browser they are) and blank referer headers (in other words, they don’t specify which URL they arrived from). Enabling this option will not only prevent requests like this from reaching your site, but it will also immediately block the IP address the request originated from. Note that both User-Agent and Referer must be missing from the request for this blocking rule to take effect.
Custom text shown on block pages
When Wordfence blocks a visitor or bot, general information about the block is shown. Using this field, you can include an additional message, such as information about how to contact the site owner, in case the block was unintended. Only plain text should be included, as HTML will be removed before the text is displayed. Similar to the WordPress page editor, double line breaks are converted to paragraphs, and single line-breaks are replaced with break (br) tags.
Check password strength on profile update
If you enable this option, it will not alert a user that they have a weak password, unlike the “force strong passwords” feature above. However, it will send the site admin an email alert telling that admin that a user has specified a weak password during a profile update. It simply lets you know who is using a weak password so that you can contact them and let them know that they may want to improve the password strength.
If you do contact one of your users or customers, make sure that you are clear that you do not actually know what their password is. You are only alerted that the password does not meet your site’s password strength requirements. That way they know you have not violated any reasonable expectation of privacy that they may have.
Participate in the Real-Time Wordfence Security Network
Enabling this feature causes your site to anonymously share data with Wordfence on hack attempts. In return, your WordPress site receives the IP address information of hackers that are currently engaged in brute force hacking activity so that your site can immediately block those hackers before they are able to engage in a brute force attack on your site.
When enabled, Wordfence also reports page-not-found errors, attempts by blocked IP addresses to access your site, attempts by hackers to access known malicious URLs that do not exist on your site but are clearly a hack attempt, and login failure attempts. No personally identifiable data is sent, and we also don’t associate any of the data we do receive with your specific website. We aggregate the data on a real-time platform to determine which IP addresses are currently engaged in the most malicious activity and need to be blocked by our community. That data is then used by your site and other Wordfence protected sites to block those malicious IP addresses.