This is the maximum number of login failures allowed for a given IP before the login process is disabled for that individual.

Sometimes attacks come from multiple IPs on the same network. This limit applies to the number of failures attributed to a network subnet (/24 for IPv4 and /64 for IPv6). It is recommended you set this value 4 to 5x higher than the individual fail limit.

An individual IP or entire network subnet will be banned from logging in so long as their total number of failures within this window exceeds the limits set. The ban will be lifted once this no longer applies (i.e. the first counted failure expires).

If it helps, the current value translates to {{settings.login.fail_window / 60 | round:2}} hours. :)

When someone successfully logs in, their prior failures are no longer counted against them, even if they are within the fail window.

It is very important you avoid getting yourself or your coworkers banned (the latter happens frequently in office environments where multiple employees fail around the same time). You should whitelist any IP addresses, ranges, or subnets from which you will be connecting.

Your current IP is:

This option adds a hidden field to the standard wp-login.php form to help ensure that login attempts are actually originating there (rather than coming out of the blue, as is typical of robotic assaults). Do not enable this option if your site uses custom login forms or if the login page is cached.

This will send an email to the account user whenever access is granted to an IP address that has not successfully logged in before.

Note: this depends on the data logged by the plugin, so if you have configured a short retention time, it may not be very useful.

This will cause the email alert function to use subnets rather than individual IPs when determining "newness". This setting is recommended for IPv6 users in particular as their IPs will change frequently.

In order for IP addresses to be correctly logged,the plugin needs to know where to look. If your server is behind a proxy, the default REMOTE_ADDR may show the forwarding server's IP instead of the user.

In such cases, you can browse the list above to find the value that correctly reports your IP address.

Note: alternative values are possibly subject to forgery; use at your own risk!

Logging hundreds or thousands of login attempts every day can accrue a lot of data. Unless you are a crazy statistician, you probably don't need to retain the records indefinitely.

Data older than the specified number of days will be automatically removed from the system.

This determines whether or not user passwords must contain letters.

This determines whether or not user passwords must contain numbers.

This determines whether or not user passwords must contain special symbols.

The minimum length for a user password. 10 is a good place to start.

Apocalypse Meow automatically prevents users from choosing any of the 500 or so most common passwords. This protection is mandatory and cannot be disabled. ;)

This option vastly increases the cryptographic security of stored user passwords by running 2^15 iterations of the bcrypt hashing algorithm. This will make it much harder for a hacker to decrypt the user list should they gain access to your database. But it comes with some important caveats, so only enable this if you know what you are doing!

Warning: This is intentionally not backward compatible with WordPress default hashes. All existing logins will be invalidated if enabled. (The reverse, however, is not true; if you disable this option, WordPress should still be able to process logins that have the extra encryption.)

Warning: Depending on your hardware, user logins might take a very long time. This is only recommended for sites running on a VPS or dedicated server.

Warning: The resulting hash is 60 characters in length, which might be longer than a theme or plugin is expecting. (Though it would be unusual for a theme or plugin to process user logins!)

WP-REST exposes site data through a new RESTful API. It is a neat feature, but isn't yet widely adopted by themes and plugins, and potentially gives attackers easier access to information (such as user enumeration).

It is recommended you disable or at least restrict access to this feature if you don't need it to be public.

WordPress adds information about next and previous posts in the HTML <head>. This isn't usually a big deal, but can help robots find pages you thought were private. This is just robot food, so you can safely remove it.

WordPress comes with the ability to edit theme and plugin files directly through the browser. It is dangerous to modify third-party files, particularly if you don't know what you're doing (plus they'll just be overwritten on update anyway). If you're a developer, you should just use FTP like a sane person. In other words, this should be disabled. ;)

Note: This will have no effect if the DISALLOW_FILE_EDIT constant is defined elsewhere.

By default, WordPress embeds a version tag in the HTML <head>. While this information is largely innocuous (and discoverable elsewhere), it can help nogoodniks better target attacks against your site, particularly if you are running an out-of-date version of WordPress. Since this is really only something a robot would see, it is safe to remove.

WordPress releases include a publicly accessible file detailing the version information. This is one of the first things a hacker will look for as it will help them better target their attacks.

Click here to view yours. Your server does not currently have a readme.html file. Checking this option will ensure that it never does.

Any links on your site that open in a new window (e.g. target="_blank") could potentially trigger a redirect in your site's window. This opens the door to some sneaky phishing attacks. See here and here for more information.

This option adds rel="noopener" to vulnerable links on your site, which is meant to disable this capability. It is a lightweight and non-destructive approach, but doesn't protect all browsers.

For a more comprehensive solution, take a look at blankshield.

Ever wonder how a robot guessed your username? There's a neat trick that exploits a weakness in WordPress' permalink rewriting: visit ID)); ?> and you should be redirected to a pretty URL ending in your username. Robots simply try ?author=1, ?author=2, etc.

This setting blacklists that particular query variable so it cannot be used by robots... or anyone. Do not enable this setting if any of your themes or plugins lazy-link to an author's ID instead of their actual archive URL.

Note: this setting will also disable the WP-REST "users" endpoint in WordPress versions 4.7+. To restrict API requests for user information in earlier versions, alter the WP-REST access setting at the top of this section.

By default, this plugin simply redirects any ?author=X requests to the home page. But if you enable this option, it will instead trigger a 400 error and exit. This approach uses fewer resources and can more easily integrate with general log-monitoring policies.

Note: WP-REST requests will always result in an API error.

WordPress comes with an XML-RPC API to let users manage their blog content from mobile apps and other web sites. This is good stuff, but is also a common (and powerful) entry point for hackers. If you aren't using it, disable it. (Some plugins, like Jetpack, need to hook into this feature. Just re-enable it if something breaks.)