Brute force protection is turned on when you enable it in your Attack Protection settings. It covers the passwordless endpoints, regardless of whether sign-up is enabled/disabled. The documentation you linked suggests using brute force protection to guard against user enumeration attacks, an added risk for disabled signup-ups.
Would it be possible perhaps to make this clearer in the documentation? as it currently seems that the brute force policy for passwordless is distinct somehow or subject to different requirements.
Inside the team here, our qa person asserts that the public ip they use is fixed (permanent), yet they report being unblocked from a brute force block on passwordless after only 24 hours.
What they did to prompt the block was to repeatedly enter the wrong code a large number of times.
Unfortunately, I don’t have a lot more than this to go by. We’re using Axios to run the flow via passwordless endpoints, ie. /passwordless/start and /oauth/token with a http://auth0.com/oauth/grant-type/passwordless/otp grant type.
@dan.woda it’s very clear for us that it was neither. We have disabled brute-force related emails as we’d prefer having admins unblock any blocked account, but this is a qa environment.
It’s really only the one qa engineer. With that having been said, I will ask him to time his next set of tests, so we can confirm that the ip we are seeing in the logs is consistent with the fix ip we expect.
How are you able to determine the user was blocked?
The QA engineer who blocks this account intentionally has simply shared his screen with me as he was doing it, until we both saw the standard error message Your account has been blocked after multiple consecutive login attempts. We've sent you an email with instructions on how to unblock it.
We do not get that email message though, since the feature is disabled for us.
I do get an entry in the logs, of type "type": "limit_wc"
I am trying to confirm if the IP we see is indeed the fix one that we expect, as this might explain why we are getting unblocked shortly after.
I just wanted to report another issue we encounter related to blocking. I wouldn’t group these together usually, but since they both pertain to blocking, I’ll mention.
We use another account for load testing (k6).
Once per test/session, the account is either created, or retrieved by email, logged in to, and then we use the token to authenticate whichever operations under load testing.
However, yesterday, I started receiving a 429 error on that account, with the same message as above. I went to unblock it manually from the Auth0 dashboard, and to my surprise the account is not present there anymore.
There is a passwordless account using the same email address, but the one that we were using for load testing has quite simply disappeared.
Ok, so: I can confirm that the IP logged on Auth0 is not the fixed ip we intended, which is why this user is being unblocked relatively easily. This is on us, it appears we are using a proxy for these.
Regarding the other error reported above, I am still getting to the root cause, but the users are at some point switched from a db connection to a passwordless one (email), which is why they are eventually brute-force blocked later down.
I’m happy to help with this additional issue. In order to help you, I need steps to reproduce the issue on my side, or evidence of the behavior occurring. Can you please take a screen recording providing evidence of a user disappearing, or provide reliable steps to reproduce?