auth.signUp() doesn't error for existing accounts - security vulnerability

[CalebLovell]

Bug report

Describe the bug

supabase.auth.signUp() is not erroring for existing accounts. Right now, you can submit an existing email with any incorrect password, and supabase will return you the account metadata (without a jwt).

To Reproduce

Go to this example app
Sign-up with an email and a password
Log out
Try to sign up again with the same email using any password you want. Try asdfasdfasdf if you want!
You will get an alert saying you logged in, but you won't get a working access token. Just the email you submitted.
You can also view the request in the Network tab of the Dev Tools and see metadata about the account, like when it was created and what provider it uses.

Expected behavior

Attempting to sign up with an existing email should throw an error.

System information

• Version of supabase-js: [1.2.1]
• Version of Node.js: [14.17.4]

[awalias]

hey @CalebLovell this is actually a fix for a previous security issue.

Previously the interface was leaking information by allowing an attacker to see whether a given email had an account or not. Now the endpoint returns a "success" response regardless of whether an account exists already or not.

The metadata you see in the response is actually faux info - the user ID is random and the datetimes are set to the time that the request was made.

note: this is only the case for supabase instances where AUTOCONFIRM is disabled (as per the default)
for accounts who have enabled AUTOCONFIRM (where accounts don't require email confirmation) the behavior is the same as before (error on duplicate accounts)

hope this helps!

[CalebLovell]

Ahh, very interesting. Would be great to maybe add that to the docs somewhere, because I suspect I won't be the only one confused by it. Firebase returns an error in this situation so that is what I was expecting, but I like the faux info return as an even better solution! Thanks for the response and enjoy your weekend.

[naegelin]

This 'security fix' seems like 'security through obscurity' . IMHO it doesn't make sense for supabase to be opinionated about how a signup process should be handled by developers. There are many use cases where a back-end service may need to know if a user already exists and having to store an additional user profile table just to be able to figure this out seems to be an unnecessary extra step. Perhaps the 'service key' responses can be accurate while the 'app key' responds with a generic 'invalid credentials'?

[brunobely]

In the case where a user forgets they are already signed up with their email address, most websites will show some variation of “there’s already an account for this email address”.

If a user tries to sign up with an email that already has an account associated with it, how can I tell so I can let the user know?

[silentworks]

I also agree that security through obscurity is not a good way to fix this as most services online do tell you if a user already exists, what they do have however is a rate limit on how many logins you can try within a certain time period to prevent brute force attacks. This fix should probably be reverted as the behaviour is unexpected and it seems to be confusing users more than anything.

[serranoarevalo]

@awalias so if the user is trying to create an account, when they already have one, is there a way to let me know?

[ChronSyn]

I also agree that security through obscurity is not a good way to fix this as most services online do tell you if a user already exists, what they do have however is a rate limit on how many logins you can try within a certain time period to prevent brute force attacks. This fix should probably be reverted as the behaviour is unexpected and it seems to be confusing users more than anything.

Correct. Rate limited logins would be the correct process for this, but it's also difficult to defend against some forms of attack unless they are targeting one specific account, in which case locking that account from logging in for a duration or until an account owner performs some verification process.

If an attacker is aiming to test as many accounts as possible, then the options are either cookies (easily defeated) or IP blocking (also easily defeated). There's some hybrid options out there such as behaviour analysis, but they have their own set of limitations and potential for false positives.

Rate-limiting registration isn't feasible to introduce as an attacker could easily bombard the system with fake registrations and block legitimate users from registering. For ecommerce sites, this would potentially make it a haven for scalpers. At the same time, it becomes difficult for developers when they're unsure if an account exists during registration.

What most online services have is a generic truthy response during the account recovery process. For example, instead of saying "An email was sent to the account we found", they'll instead say "If an account with this email exists, we have sent an email to it". I believe rate limiting per account already exists for this in Supabase.

It's a difficult problem to solve because there's potential for hackers to use the sign up process to ascertain if an account exists (as opposed to testing login), but developers want to know if an account exists when a user is registering.

[naegelin]

Every security control can be defeated. Supabase shouldn't be responsible for solving every edge case of security for app developers and many companies have regulatory guidance on how to implement authentication flows. There should be a straight forward api available for server to server calls so that developers can decide what the proper pattern would be for themselves based on their own needs. The current Supabase position is to create an associated "user profile" table inside supabase in order to recreate missing functionality (such as basic checks to see if a user exists). The more of these types of work arounds a developer needs to create, the less compelling supabase becomes over say a vanilla postgres + hasura instance. I would also argue that for B2B applications where access is not available to the general public many of the concerns around account harvesting, fake registration etc are much less of an issue.

[brunobely]

@awalias so if the user is trying to create an account, when they already have one, is there a way to let me know?

Building off of this, I think the crux of this issue and what we want to know is what should an average auth flow look like, implementation-wise, when built with Supabase? The only guide available in the official documentation uses magic links "for simplicity" but doesn't really touch on how to handle any error or edge-case scenarios, which is extremely important in production.

I'd just like to know how to do it properly, whichever the security measures taken are.

[awalias]

Hey everyone thanks for your comments!

To be clear this is not an example of security through obscurity, the red herring here might be the presence of faux info or the fact that we haven't done a good job of documenting this behavior. As long as we don't leak any info about whether a user account exists or not on any public endpoint, then the information is secure (at least as far as this specific issue is concerned).

The correct solution here is to take this one step further: If a user tries to sign up who already has an existing account, we still return a "check your inbox for confirmation email" message, but we instead send them an account recovery email (which is actually just a magic link) then the developer can decide whether to direct them to a password reset page or just allow them to go about their session as normal.

This solves for:

• UX concerns (a user who has forgotten that they have an account and is expecting a confirmation email, will receive an account recovery email - note: the developer can edit the template in supabase dashboard)
• DX concerns (there should be no extra call required to detect account existence and trigger account recovery)
• Security (the presence of an account is never revealed on any public endpoint)

An important reason for why we decided to be "secure by default" on issues like this, is partly because of the number of users adopting our auth service. I could fairly easily take your email address, make a sign-up request to every known supabase endpoint on the internet, building up a map of all the various services that you are/are-not subscribed to. Which is quite a large privacy concern.

I propose that we do several things:

• Document the response behavior clearly in the docs
• Update our auth examples to exhibit the up to date auth flow
• Update gotrue to send a recovery email on repeat sign up attempt

As always any help on these ones would be hugely appreciated. And thanks again for the active discussion and helping improve the product 🙏.