ROPC Login with Brute-force - "Blocked" status should be returned a step earlier

Help
,
1

Hi Experts,

We are trying to leverage ROPC flow from Auth0 where API will be shared with Application Developers.

Knowing the fact that ROPC is not a recommended approach, the application is also considered a highly trusted one by conducting even the smallest level of code assessment to ensure confidence that user credentials cannot be compromised.

In order to use ROPC API on development perspective where Application will be building their own UI for login (for Auth0 it is going to be purely REST API based), but relying on the response from Auth0 as part of authentication process by calling ROPC Login flow (Auth0 API). Pls suggest how below scenario can be handled on OOTB (with default ACTIONS, and possibly as less API calls other than ROPC).

Suppose Auth0 has Brute-force Protection enabled with the Login Threshold set to 10. A user has now made their 9th consecutive invalid attempt. The user experience in this case is as follows:

  1. Fair outcome: The user receives an email to unlock their account, as it is set to trigger after 10 invalid attempts.
  2. Technically unfair outcome: Following point #1, since the account is now in a BLOCKED state, the HTTP response from Auth0 should differ from the one provided during the 10th invalid attempt - HTTP 403 FORBIDDEN. However, on the 10th invalid attempt, the ROPC API still returns HTTP 403 FORBIDDEN instead of the expected HTTP 429 - Too Many Requests. The HTTP 429 response, which indicates that the account is now BLOCKED, is received on the 11th login attempt but was expected on the 10th invalid attempt.

This is an exceptionally rare scenario and appears to be unhandled OOTB. On assumption that Auth0 would be first checking the user’s status before making the actual authentication call behind the scenes, even if the user is attempting to log in with the correct/valid password. This behavior is evident from the 11th attempt, where the account is correctly identified as BLOCKED during the same ROPC Login API call.

When could this scenario be misleading?

The user has already reached the threshold for login attempts by making 10 consecutive invalid attempts. However, if the user somehow discovers their valid password before making their 11th attempt (whether valid or invalid), they will still be unable to authenticate. This is because the account remains in a BLOCKED state and will not allow any further attempts, even with the correct password, until the account is UNBLOCKED.

Response from ROPC Auth0 API, till 10 consecutive invalid login attempts:

image
image1276×235 21 KB

Response from ROPC Auth0 API at 11th or further login attempts:

image
image1324×268 28.4 KB

Pls help or suggest the best way to handle this scenario.

Regards,
Aditya

3

Hi @aditya.b.gautam

Welcome back to the Auth0 Community!

Thank you for posting your question. In short, this feature works as expected, and it would be best if you could open a new thread in the feedback category with a proposition on how you would like Brute-force protection to work. Feedback

However, there’s a workaround that will not entirely solve the issue but will make the flow clear for the customer.

It is possible to add a static message to the login prompt indicating the maximum number of login attempts a user can make. If a tenant admin changes the tenant’s brute force protection thresholds, this would need to be updated separately.

For example: when using the Identifier First authentication profile, the “description” for the “login-password” screen could be edited to advise users they only have 5 total attempts before the account will be blocked. For an Identifier + Password authentication profile, this could be put instead on the “description” of the “login” screen → Customize Universal Login Text Elements

Thanks
Dawid

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.