We have an application which creates Auth0 passwordless accounts as part of an integration with a separate system.
For this reason, we have disabled (passwordless) sign-ups.
About brute-force protection though, the documentation isn’t very clear.
Is brute-force protection enabled at all on passwordless logins? Or is it enabled when sign-ups are disabled? If the latter, is it subject to the same unblocking rules as other protected flows?
I am asking because we have observed this blocking behavior in testing, and we’ve seen these accounts become unblocked seemingly automatically within a couple of days.
If the 30 days limit isn’t strictly enforced, are there settings we can adjust to determine our own time frame?
Thanks in advance for your help and clarifications regarding this.
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.
If you see other behavior, I’d be happy to try and reproduce and confirm so I can pass the feedback along to our team. If this is the case, please share some steps to reproduce. Thanks!
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?
Thanks for clarifying this. I wasn’t aware of the load testing policy. Does it also apply to jwks/signature requests?
To hopefully explain our flow a bit better. Initially, in load testing, we:
Checked the existence of a given test user on Auth0.
If the user didn’t exist, we created them (via management api).
Then authenticated as them.
Passed the access token down through all subsequent load tests, so no re-auth.
Load tests were performed against our own back-end, which only validates the token signature (jwks) and makes no other calls to Auth0.
However, for reasons not entirely clear to me, this flow resulted in the user’s connection being changed in their profile from password-based (database) to passwordless (email).
This had me confused and I believed the test user had been deleted, but it’s just this one thing, the connection, that gets changed.
As a result, subsequent attempts to login with a password grant eventually resulted in the user being blocked.
Since then, we’ve updated our flow to create the user with a random suffix at the beginning of a load test, and delete them afterward.
Kindly note that this development was done against a dummy endpoint (no jwks), with loads against Auth0 not exceeding one user creation/auth/deletion per test session.
To conclude, I have conducted two real nine minutes sessions - I had to, due to time constraints. Though I believe I have kept things moderate and well-within quotas for standard usage.