Docs / Login security

Limit login attempts

How the brute-force limit works, the two numbers that control it, and what a blocked visitor sees.

All documentation

A brute-force attack is a script trying passwords until one works. The defence is simple: after a few failures from the same address, stop answering. FluentAuth does this on wp-login.php, on the block editor’s own login, and on every form built with the shortcodes. Since 3.0 it also covers application passwords, which authenticate without ever reaching the login form.

The two settings

Under Settings → General Settings → Login Security:

SettingDefaultMeaning
Maximum failed attempts5Failures allowed from one IP address before it is blocked
Within (minutes)30The window those failures are counted in, and how long the block lasts

Both are required. The limiter cannot be switched off from the settings screen; since 3.0 a developer can disable it with the fluent_auth/login_security_enabled filter, which is the right place for a staging site that runs automated logins.

What happens at the limit

  1. The sixth attempt (with the defaults) is refused before WordPress checks the password, with a message saying the address is blocked and for how long.
  2. The attempt is written to the audit log with status blocked.
  3. If notifications are on, you get an email naming the address and the username it tried.
  4. After the window passes with no further attempts, the address can try again.

A successful login from an address clears its count.

One account, many addresses

SINCE 3.0

The account-level challenge described in this section was added in FluentAuth 3.0.0. On earlier versions the limit is counted per address only.

Attackers who know the limit rotate addresses, so a single account can be hit from hundreds of IPs with a few tries each. FluentAuth watches for that too: when failures against one account exceed three times the per-IP limit across all addresses, the next correct password from a new address is not enough on its own. The user is asked for a code sent to their email before a session is issued.

This is a challenge, not a lockout, so an attacker cannot lock the real owner out of their own account by hammering it. An address that has signed in to that account before is trusted and skips the challenge. The multiplier is filterable with fluent_auth/account_attempt_limit.

Application passwords and headless logins

SINCE 3.0

Application password limiting was added in FluentAuth 3.0.0. You can also turn application passwords off entirely.

Core WordPress lets application passwords authenticate without the login form, and the failure path bypasses the normal hooks. FluentAuth hooks that path separately, so a script guessing application passwords hits the same limit and appears in the same log. If you never use application passwords, turn them off altogether.

Whose address is it?

Behind Cloudflare or a reverse proxy, every visitor can appear to come from the proxy’s address, which would block everyone at once. FluentAuth detects Cloudflare automatically and lets you declare other trusted proxies; see Visitor IP and proxies.

Allowing and blocking addresses outright

For an office address that should never be limited, or a range that should never reach the form at all, use IP access rules.

TIP

Locked yourself out while testing? The block is per address, so sign in from a phone on mobile data, or wait out the window. Nothing needs to be reset in the database.