A brute force login attack consists of a large amount of repeated attempts at guessing your username and password to gain access to your WordPress administration screen. These attacks are automated, and the usernames and passwords used for guessing typically originate from large 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.

Options

The “Brute Force Protection” options are found via the “All Firewall Options” link on the “Firewall” page.

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 opportunities to login, but will block a brute force login attack after 20 attempts.

Lock out after how many forgot password attempts

This limits the number of times the WordPress “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 from 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. For example, if you specify 5 minutes and 20 failures, then if someone fails to login 20 times during a 5-minute time period then they will be locked out from accessing the login page. 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 prevent a brute force login 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 site’s usernames and passwords. If you have reasonably strong passwords, then it will take many thousands of guesses to guess your password correctly.

For example, 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 are locked out. Therefore, 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 login 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 or 2 administrators and/or possibly a few editors. If a legitimate user is locked out then you can find and unblock the IP address of that user on the Wordfence “Firewall” > “Blocking” page.

Immediately block the IP of users who try to sign in as these usernames

Any username you add to this option will cause an IP address to be blocked if it tries 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 typographical error.  Note that if you add a username to this option for a user account that already exists with that username then any IP address that tries to login with that username will not be blocked by this option.

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 administrators who use such passwords, or you can choose to let this option apply to all users who have the “publish posts” privilege (that includes administrators). The default setting is to only block administrators.

What is a password leaked in a data breach? When large 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 that try to login 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

With this option, you can select either “Force admins and publishers to use strong passwords (recommended)” or “Force all members to use strong passwords”. We recommend you force administrators and publishers to use strong passwords. When a user on your WordPress site changes their password, Wordfence will check the password to make sure it is strong enough to provide a good level of protection. If the password fails this check then it is rejected and the user must enter a stronger password.

A new password must meet the following specific requirements to reach a required point score:

• At least 12 characters.
• At least one of each: uppercase letters, lowercase letters, numbers, symbols.
• No character may be repeated 3 or more times.
• No ordered numeric sequence of more than 2 characters is allowed (i.e. 123 or 321).
• No ordered or patterned sequence of adjacent characters of more than 3 characters (i.e. abcd, abab).

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 security problem because it allows users to 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”. This protects your usernames and does not reveal if the hacker guessed a valid username. It is recommended that you enable this feature.

Prevent users registering ‘admin’ username if it doesn’t exist

If you disable and remove the “admin” username account in WordPress, and you have user registration enabled in WordPress, then it is possible for users to register an account with the username “admin”. This can cause confusion on your system and may allow those users to persuade other users of your system to disclose sensitive data. Enabling this option prevents this from happening so we recommend that you enable this option.

Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, the WordPress REST API, and WordPress XML Sitemaps

On a WordPress system, it is possible to discover valid usernames by visiting a specially crafted URL that looks like one of these:

• example.com/?author=2
• example.com/wp-json/oembed/1.0/embed?url=http%3A%2F%2Fexample.com%2Fhello-world%2F
• example.com/wp-json/wp/v2/users

As of WordPress 5.5, authors may also be listed in built-in XML sitemaps. 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 the 4.7 version of WordPress.

Note that some themes and plugins can also leak usernames, and we can not prevent username discovery when a theme or plugin 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.

Disable WordPress application passwords

WordPress 5.6 adds the ability for all user roles to use “application passwords”, to allow a third-party site or application to access your site as your own login, but with a separate password. Application passwords can be safe to use, but in some cases, the setup process could be used to trick users into linking their WordPress login to a malicious site, and the messaging may not be clear enough for some users to understand how much access they are allowing. This option is active by default in Wordfence 7.4.14 but can be disabled if you want to use application passwords. When Wordfence has disabled application passwords, if you try to set up a new application password, it will display the message “Application passwords have been disabled by Wordfence”.

Block IPs who send POST requests with blank User-Agent and Referer

Many badly written brute force login hacking scripts send login attempts and comment spam attempts using a blank User-Agent header (in other words, they don’t specify which browser they are) and blank Referer header (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 will also immediately block the IP address the request originated from. Note that both the User-Agent and Referer headers must be missing from the request for this blocking rule to take effect.

If you use external services that may send POST requests without these headers, do not use this option, as they will be blocked. This is uncommon, since most services will set the User-Agent header to identify their service, but we have heard of a few cases where a legitimate service did not include it.

Custom text shown on block pages

When Wordfence blocks a visitor or a bot, general information about the block is shown. Using this field, you can include an additional message for people, 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 “Enforce strong passwords” feature above. However, it will send the site administrator an email alert telling that administrator 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 about 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 back to us the following:

• 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
• Login failure attempts.

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.

Why you shouldn’t change or hide the login URL