createUserWithEmailAndPassword overwrites if exist

[streamly]

$auth = $service->createAuth(); This seems to be a bug but not sure if it is with this code or supabase. If this is called and the user exist, the password and any metadata passed is overwritten.

Possible security issue that someone could reset another user's password using just the signup form.

I am still developing and testing but I think an error should be returned if the email already exist.

Also, it says confirm email is sent but supabase seems to send if new and not already exist.

try{ $auth->createUserWithEmailAndPassword('xxx@yahoo.com', 'bxxxy'); $data = $auth->data(); // get the returned data generated by request echo 'User has been created! A confirmation link has been sent to the '. $data->email; } catch(Exception $e){ echo $auth->getError(); }

[rafaelwendel]

hello @streamly

Despite the $service->createAuth() method returning a json with the supposed user data, in Supabase the data (password and any metadata) will not be overwritten and the email will not be sent. Therefore, it is not possible to overwrite a user's data if the email already exists.

It would be better if the response to this request in Supabase returned more user-friendly information (like a message stating that the email is duplicated).

=)

[rafaelwendel]

@streamly

I was looking at this issue (https://github.com/supabase/auth/issues/1517) on Supabase's github and found the following answer.

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)

[streamly]

Thanks for the reply and looking into it. I sent supabase an email about this issue. There should (or could) be something returned on the server side if the developer wants to implement something. Not sure if they could create a better solution to the attacker problem or at least offer it as an option. If an user forgets they signed up (it's happen to me) they now sit waiting for a confirmation email that will never be sent. I got my forms integrated with google recaptcha to reduce the attacker risk. Surely, adding some ip/session sign up/in requests limits would be more user friendly. :-)