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?
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.
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.
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.
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 at which point it may become cheaper to just build our own authentication server.
Hi @john.gateley,
The purpose of account enumeration protection isn’t to stop bad actors from creating a bunch of accounts, that’s just the result.
The purpose of account enumeration is to know with certainty which customers already exist on your platform. Depending on the platform, the bad actor can then use this data for additional attack vectors like spearphishing.
Is there now a way to customize the signup experience similar to what the thread author suggested initially?
In our company, we’re currently going through a pen test performed by an external, and they have told us that the way in which the signup process works currently may lead to user enumeration. They have suggested us the following:
Registration: As a best practice to prevent usernames from being enumerated when creating an account, the username should be an email address. When an attempt is made to create a new user account, the same message can be displayed regardless of whether the email address exists in the system or not, for example:
“A confirmation has been sent to the email provided.”
Is there a way in which we can achieve something like this with Universal Login?
at which point it may become cheaper to just build our own authentication server.