One of the ways attackers try to break in to your site is by guessing your username and password. They try to figure out valid usernames and then try lists of common passwords in hopes of successfully logging in. These “dictionary attacks” are a type of brute force login attack.
Wordfence includes a number of powerful brute force protection features that can be used to prevent malicious bots from gaining access to your site, including the integration with Troy Hunt’s version 2 of the Pwned Passwords API that prevents access using passwords previously seen in a breach.
When you install Wordfence for the first time, the plugin defaults to recommended settings that are a perfect starting place for customization. You won’t need to do much else. However, Wordfence is highly configurable, allowing you to tailor how it works to meet your needs.
Factors to consider when modifying your site’s brute force protection settings include:
- How adept are your users? Do you have users that forget their passwords often? Are they logging in sporadically and have a high probability of losing their passwords? You’ll want to take them into consideration and allow room for user error.
- Is this a high traffic, high profile site that often experiences hacking attempts?
- Is your site under repeated attack from brute force attempts?
Your first decision is how many failed login attempts to allow and over what time period to count failures. The default configuration allows up to 20 failures over a 4 hour period. If you have a lot of users, especially ones who are more prone to forgetting their passwords this may be perfect for your site.
However, if you only have a small handful of users who are highly technical you might want to tighten these up. At the extreme, we have some customers who only allow 2 login failures over a 5 minute period.
Your next decision is how many times the “forgot password” form on your site can be used. This protects you against having your “Forgot password?” form used to flood a real user’s inbox with password reset emails, and prevents attackers from trying to guess user accounts on your system. The default value is 20. Setting this to 5 should be a safe choice for most sites and many site owners get even more aggressive.
Next you need to decide how long to lock a user (or attacking IP) out once they’ve exceeded one of your login failure thresholds. The default value is 4 hours. Many sites increase this value to a day. Sites with a more aggressive posture often set this to a month.
Advanced Bot Protection uses advanced mathematical formulas to differentiate between bots that are beneficial and those that are harmful.
The big downside to being overly aggressive with these settings is that you risk locking your users or yourself out of your site for an extended period of time. Consider what you’ll do in these situations when making these decisions.
Immediately locking out users (or IPs) that use an invalid username is another option. By default this option is turned off, as it significantly increases the chances that you or another admin will accidentally lock yourself out of your site. If you’re confident that you can avoid locking yourself out, or you have a backup plan should it happen, enabling this option can go a long way toward locking down your site.
If the previous option is too aggressive for your site, we also provide an option to lock out attackers who use a specific list of usernames. Most of the attacks we see attempt common usernames such as ‘admin’, ‘administrator’ and different strings based on your domain name. Coming up your own list based on predictable guesses can be very effective.
The next option to consider is to prevent the use of passwords leaked in a data breach. This is enabled by default, with “For admins only” selected. To lock your site down even tighter, consider changing this option to “For all users with publish posts capability”.
There is an important set of options in the “Additional Options” section for you to consider as well. We recommend that most site owners leave the default configuration in place. They are:
- Enforce strong passwords
- Don’t let WordPress reveal valid users in login errors
- Prevent users registering ‘admin’ username if it doesn’t exist
- Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, and the WordPress REST API
- Block IPs who send POST requests with a blank User-Agent and Referer
- Custom text show on block pages
- Check password strength on profile update
- Participate in the Real-Time Security Network
Finally, the Wordfence real-time IP blacklist does a great job of blocking IPs that are actively attacking WordPress sites. Consider upgraded to Premium to enable this powerful feature.
By Mark Maunder – Wordfence Founder & CEO
