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