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:
| Setting | Default | Meaning |
|---|---|---|
| Maximum failed attempts | 5 | Failures allowed from one IP address before it is blocked |
| Within (minutes) | 30 | The 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
- 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.
- The attempt is written to the audit log with status blocked.
- If notifications are on, you get an email naming the address and the username it tried.
- 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
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
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.
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.