Brute Force Protection

Brute Force Protection guards your WordPress login form against automated password-guessing attacks. It works by tracking failed login attempts per IP address, locking out IPs that fail too many times in a row, and refusing to confirm or deny the existence of usernames an attacker is probing.

This is one of the highest-value features in VMP Security. Login-form attacks are by far the most common way WordPress sites get compromised, and they are easy to defeat with sensible thresholds — an attacker who can only try five passwords per hour will not break a non-trivial password before the heat death of the universe.

In This Article

• Enabling Brute Force Protection
• Configuring lockout thresholds
• Enforcing strong passwords
• Username harvest protection
• Trusted IP bypass

Enabling Brute Force Protection

Brute Force Protection is on by default. Confirm or change its state from VMP Security → Firewall — the Brute Force Protection card on that page has a single toggle.

Detailed thresholds (lockout duration, max attempts, immediate-block triggers, and trusted IPs) are configured on the Firewall → Firewall Options page, in the Brute Force Protection section.

Configuring lockout thresholds

On the Firewall Options page you can adjust:

• Maximum number of login failures before an IP is locked out.
• Maximum number of forgotten-password attempts before lockout.
• Lockout time period (default 4 hours / 240 minutes).
• Immediately block invalid usernames — a separate, lower threshold for attempts using usernames that do not exist on the site.
• Lockout when an attempt is made using a known invalid username.

The default for failed login attempts is deliberately not set to 1 or 2, because legitimate users mistype passwords; you do not want to lock out real customers or staff. The default for invalid-username attempts is much lower because a request for a username that does not exist is almost always automated and is a strong signal of an attack.

For high-value sites you can tighten these. Some practical settings:

• 10 failed attempts in 5 minutes for an admin-only site (no public login form).
• 5 failed attempts with a 24-hour lockout for sites where you care about sustained attacker pressure more than user friction.
• 1 invalid-username attempt for any site — legitimate users do not normally try usernames that do not exist.

Enforcing strong passwords

Lockouts only matter if the password an attacker is trying to guess is hard enough that they need many attempts. The Strong Password Enforcement section forces users at specified roles to set a password that meets the WordPress password-strength meter’s “strong” threshold.

• Enforce for administrators. Strongly recommended. Administrator passwords are the highest-value targets on a WordPress site.
• Enforce for editors. Recommended. Editors can publish content, including content that contains JavaScript on sites where unfiltered HTML is allowed.
• Enforce for all users. Sensible for ecommerce sites and membership sites where customer accounts hold payment or personal information.

When enforcement is on, users with weak passwords are required to change them on their next login. Existing weak passwords continue to work until then; this avoids locking out users at the moment you turn the feature on.

Username harvest protection

WordPress, by default, makes it easy to confirm whether a username exists: the login form returns one error for “wrong username” and a different error for “wrong password,” and the author archive URLs (/?author=N) leak usernames in their redirect targets. An attacker uses these to build a list of valid usernames before they ever try a password.

Username harvest protection closes both holes:

• The login form returns a single generic error message for any failed login, whether the username exists or not.
• /?author=N URLs are blocked from disclosing the username slug, returning a 404 instead of redirecting.
• The REST API endpoints that list users are restricted to authenticated requests only, with optional further restrictions to administrator users.

Combined with strong passwords and lockout thresholds, this puts an attacker in a position where they have to guess both username and password — a much harder problem.

Trusted IP bypass

If you have a fixed IP that you administer the site from, you can add it to the trusted-IP list. Failed logins from that IP do not count toward the lockout threshold. This is useful if you regularly use a password manager that auto-fills incorrectly the first time, or if you have automated tooling that needs to handle authentication failures gracefully.

Use this sparingly. A trusted IP is a real reduction in protection for that source, and an attacker who finds a way into the same network can take full advantage of it. Do not add the office Wi-Fi to the trusted list; consider adding only individual VPN exit IPs that you control.