Hi all — hoping to confirm a couple of things about brute-force protection on a database connection (Username-Password-Authentication), with the password policy set to Excellent.
-
Do submissions that fail the password policy count toward failed attempts?
We’re seeing that passwords too simple to meet the policy (e.g. abc123) don’t seem to count against a user’s failed-login count — a user could submit one repeatedly without ever getting blocked. Can anyone confirm that’s expected? And is there a way to make every failed attempt count, regardless of whether the submitted password meets the composition rules?
-
Can we override the “new IP” exemption on brute-force blocks?
We’ve noticed a user who is brute-force blocked can still log in once their IP address changes. Is there a setting to enforce the block regardless of source IP?
Related and a bit confusing: the user shows a “Blocked (Bruteforce)” banner in the Dashboard, but under Identity Provider Attributes, blocked is false. Where does that discrepancy come from — is the brute-force block tracked separately from the user’s blocked attribute? Want to make sure I’m reading the right signal when checking whether someone is actually blocked. Finally, is there a way I can see a user’s blocked status in the ID token?
Thanks in advance.
Hi @dfleming
Welcome back to the Auth0 Community!
To answer your questions:
- Do submissions that fail the password policy count toward failed attempts?
We’re seeing that passwords too simple to meet the policy (e.g. abc123) don’t seem to count against a user’s failed-login count — a user could submit one repeatedly without ever getting blocked. Can anyone confirm that’s expected? And is there a way to make every failed attempt count, regardless of whether the submitted password meets the composition rules?
This is expected. Passwords that violate fundamental schema rules (like minimum length) fail pre-authentication input validation (returning a 400 Bad Request) rather than failing the actual credential check (401 Unauthorized). Only actual credential check failures trigger the Brute-force counter.
- Can we override the “new IP” exemption on brute-force blocks?
We’ve noticed a user who is brute-force blocked can still log in once their IP address changes. Is there a setting to enforce the block regardless of source IP?
No, you cannot override this. Auth0’s Brute-force protection is intentionally scoped to User + IP to prevent Account Lockout Denial of Service (DoS) attacks.
Related and a bit confusing: the user shows a “Blocked (Bruteforce)” banner in the Dashboard, but under Identity Provider Attributes, blocked is false. Where does that discrepancy come from — is the brute-force block tracked separately from the user’s blocked attribute? Want to make sure I’m reading the right signal when checking whether someone is actually blocked.
The banner reads from the temporary Anomaly Detection system, while the blocked attribute is a permanent, administrative flag on the user’s core profile.
Auth0 maintains two entirely separate systems for blocking users:
-
The Anomaly Detection Engine: This is a dynamic, temporary memory store. When a User+IP hits the threshold, this engine temporarily throws up the “Blocked (Bruteforce)” banner in the dashboard.
-
The Core User Profile: The blocked: false attribute under Identity Provider Attributes is a permanent, manual administrative flag. It only changes to true if an Admin clicks “Block User” in the dashboard or updates it via the Management API.
Because Anomaly Detection blocks are temporary and IP-scoped, they do not mutate the permanent blocked boolean on the core profile.
Finally, is there a way I can see a user’s blocked status in the ID token?
If a user is actively brute-force blocked on an IP, they will be denied access and will not receive an ID token at all. Auth0 Actions do not execute, and an unauthorized error is returned to the frontend. Therefore, no ID token is ever generated or issued for that blocked transaction.
If the user logs in from a different IP (where they are not blocked), the login succeeds. However, Auth0 does not expose the Anomaly Detection state (e.g., “this user is currently blocked on 3 other IPs”) to the event.user object in Actions, so you cannot inject that history into the resulting ID token.
If you have other questions, let me know!
Kind Regards,
Nik
Thanks, Nik — that’s really helpful -
One follow-up, because our testing turned up something that seems to contradict the “Block Brute-force Logins” behavior. This was all on a single, unchanging IP (same IPv6 address throughout), on a Username-Password-Authentication database connection:
- Entered the wrong (but policy-compliant) password 10+ times → 10+ “Failed Login (wrong password)” events, and the user flipped to the “Blocked (Bruteforce)” banner.
- Immediately entered the correct password — from that same IP — and the login succeeded (“Success Login” → “Success Exchange”).
So even though the user was flagged as brute-force blocked on that IP, a valid-credential login from the same IP went straight through. The “Block Brute-force Logins” description (“Auth0 will block login attempts for a flagged user account”) led us to expect the block to hold until the user was explicitly unblocked.
Questions:
- Is this expected — i.e. does “Block Brute-force Logins” only throttle repeated failed attempts, while a correct credential is always allowed through (and effectively clears the block), even from the IP that triggered it?
- Is the Account Lockout option the setting that blocks all attempts to the user identifier — including a correct password — until the account is manually unblocked?
(Attaching screenshots: before, after 10+ wrong tries showing the Blocked banner, and the successful login — all on the same IP.)
Thanks again!
@nik.baleca Sorry to bother, but wasn’t sure if you saw my latest reply above.
Hi again @dfleming
I am sorry for the delayed response to your follow-up!
Yes, this is expected behavior. When the default “Block Brute-force Logins” is active, a successful login with the correct password will always be allowed through and will instantly clear the brute-force block.
To achieve the strict behavior you are looking for—where the account is completely frozen, even if the correct password is provided—you must enable the Account Lockout toggle in your Brute-force Protection settings.
1. Does “Block Brute-force Logins” allow correct credentials through and clear the block?
Yes. When you only have “Block Brute-force Logins” enabled, the block is tied to the limit_wc (Limit Wrong Credentials) condition for a specific User + IP pair.
Auth0 intentionally allows a request with the correct password to succeed from a “blocked” IP. Why? To prevent Account Lockout Denial of Service (DoS) attacks.
If an attacker knows your office’s public IP address or your home Wi-Fi IP, they could write a script to continuously spam Auth0 with wrong passwords for your username. If Auth0 rigidly blocked all traffic from that IP (including the correct password), the attacker could effectively lock you out of your own account permanently without ever knowing your password.
By allowing the correct password to succeed, the legitimate user can always get into their account. Once that successful login occurs, Auth0 registers that the legitimate user is in control and automatically resets the brute-force counter/block (which is why your dashboard banner disappeared).
2. Is “Account Lockout” the setting that blocks all attempts (including correct passwords) until explicitly unblocked?
Yes, absolutely. If your security requirements dictate that an account must be entirely frozen under attack, you need to enable the Account Lockout option.
When Account Lockout is toggled ON (it is disabled by default):
-
If the failed login threshold is reached, Auth0 locks the user identifier globally.
-
It no longer matters if the request comes from a new IP address, a VPN, or the original IP address.
-
It no longer matters if the user suddenly types the correct password.
-
All login attempts will be strictly rejected with an unauthorized error.
The account will remain completely frozen until it is explicitly unblocked. A user can be unblocked in three ways:
-
They click the “Unblock” link sent in the automated Auth0 email notification.
-
They successfully perform a self-service Password Reset.
-
An Administrator manually unblocks them via the Auth0 Dashboard or the Management API.
Kind Regards,
Nik
@nik.baleca Thanks for the information but given all that it’s unclear what the ‘Block Brute-Force Logins’ actually does other than block login attempts with an incorrect password.
Also, documentation we found directly conflicts with the fact that ‘Block Brute-force Logins’ allows for correct passwords to be accepted from the same IP.
Brute-Force Protection - Auth0 Docs
