Brute-force Block Without Password Attempt Failure in Logs

Problem Statement

We’ve been noticing users getting brute-force blocked in the Auth0 logs without any password attempt failures.

Steps to Reproduce

Perform a POST to /usernamepassword/login (classic universal login) with an incorrect state value or missing Auth0 cookies enough times to meet the brute-force threshold.

Cause

This is due to a decision not to log failed logins due to an invalid state to reduce potential noise in tenant logs, but the failure still counts towards brute-force protection as they could be a sign of an attack.

Solution

Currently, when the submission of credentials is performed with an incorrect state value or missing cookies, it will deny the user access and not log this in the tenant logs.

These failures still count towards the brute-force protection threshold trigger, so they can appear to be a user being blocked without any login activity beforehand. This could be caused by users leaving login pages open for too long and causing the state to become invalid or cookies to expire, or starting a new login transaction but submitting the credentials in a previously opened tab/window, or a brute-force attack.

As it is intended not to log these kinds of failures to reduce potential noise in tenant logs, please raise a feature request to have our product team consider alternative approaches to this if you would like to have a record of this kind of failed login.

1 Like