The User is Marked "BLOCKED(BRUTEFORCE)" although the User IP is in the Allowlist of the Brute Force Protection

[auth0.knowledge3]

Overview

The following behavior might be observed for brute force protection with IP allowlist, depending on the approached angle:

1. The user is marked as blocked by brute force, but it should not be.
2. The user is marked as blocked by brute force, but it still can login.

Here are the reproducing steps:

1. Enable the brute force protection in the tenant dashboard > Security > Attack Protection > Brute-force Protection, and configure the IP Allowlist.

2. Let a user login from one of the allowlisted IP addresses with wrong credentials multiple times (more than the brute force failed login attempts threshold).

3. Check the user’s block status which shows the user is blocked by brute force.
   a. In tenant dashboard > User Management > the user’s profile page > Details tab, it shows the user is blocked by brute force, as shown below.
   

   
   
   b. The “get user blocks” endpoint of the Auth0 management, linked below, shows the user is blocked by brute force
   • Get User Blocks
   • Get User Blocks by ID

4. Let the user log in with the correct credentials, and it succeeds. After the successful login, check the user’s block status again which shows the user is not blocked.

Applies To

• Brute force protection
• IP allowlist
• User blocked
• User blocks endpoints

Cause

1. The tenant dashboard (user profile page) calls the management API at the backend to check the user’s block status and display it.
2. The “get user blocks” endpoint of management API doesn’t take the IP allowlist into account when returning the result. As a result, the incorrect block status is returned.

Solution

1. It is a known issue, and Auth0 engineering team is working on a fix for it.
2. To determine if a user is truly blocked by brute force protection:
   a. Use the “get user blocks” endpoint of the Auth0 management to get the blocked IP, and check if the blocked IP is in the allowlist of the brute force protection.
   Here is an example response of the “get user blocks” endpoint:

   {
       "blocked_for": [
           {
               "identifier": "user@example.com",
               "connection": "Username-Password-Authentication",
               "ip": "1.2.3.4"
           }
       ]
   }
   

   b. Check limit_wc event in the tenant logs. If a user is truely blocked by the brute force, the limit_wc event is generated.
   Here is an example searching condition for limit_wc events:

   type:limit_wc AND user_name:"user@example.com"