Preventing user enumeration on sign up

We want to prevent the possibility of a malicious actor enumerating existing users via the sign-up form / API.

Currently, if a user tries to sign up with an email that already is in our system, they get an error. If they try to sign up with an email not in our system, they succeed. Therefore user enumeration is possible (regardless of whether the error specifically mentions that the user exists or not).

We’d like the sign-up form to display a success message stating that a verification email has been sent, regardless of whether the user already exists or not. We’re still beginning to find out how to achieve that.

Is this something that could be achieved with the use of hooks? Or is there another solution?

Hi @andreu

Your proposal isn’t sufficient. After a user signs up, they are logged in. This should be easy enough for an attacker to check, so merely display a “success error message” will not fool them.

If the user enumeration is critical to you, I think an invite only flow is best: have the user request an invite by providing their email, then you send a link to them to sign up. You’ll have to code some of this yourself.


1 Like

Hi John,

Thanks for the insight. Our plan was that after sign up, the user wouldn’t be able to log in until the email had been verified. I thought it was possible to disable automatic log in on sign up, but now I can’t find the option anywhere, so maybe it’s just my memory playing tricks on me.

If we cannot disable log in on sign up, then you’re right that our idea will not work.

Actually looking at the signup process, it seems there is a call to /dbconnections/signup, which doesn’t return any authentication data, and then another call to /usernamepassword/login.

So I’m probably missing a lot of details here, but it would seem that the call to “signup” does not log the user in, rather it’s the client-side code that calls “login” after the user has signed up.

But if we alter that behavior on the frontend (so we point the user to check their verification link after sign up, instead of directly logging them in) and prevent login for unverified emails on the back-end side (with a rule) then maybe that would do the trick? Although that would require that the error in the “email not verified” condition be the same as the error for the “wrong password” condition.

Hi @andreu

That approach might work, but you are messing with undocumented endpoints, and Auth0 can change the behavior of those without notice. So I wouldn’t recommend this.

I was thinking about this after I replied earlier: why is the enumeration important to you? A different approach here is to implement a filter on account creation - to identify bad actors who are creating lots of accounts. Our bot detection might help with this. That would have the side effect of preventing enumeration.


1 Like

Hi @john.gateley , thanks for your help

You’re right, what I said doesn’t sound like a very solid solution.

Preventing account enumeration is being mandated on us by external processes. As you say, preventing bots from using sign-up too much would hinder automated account enumeration, which is a really good idea. I’m just not sure that this would tick all the boxes.

And there’s also the fact that using the bot detection feature would require us to upgrade to the next plan, multiplying our costs by about 10x :wink: at which point it may become cheaper to just build our own authentication server.