Change HTTP response and mail for already registered mail situation in "register" endpoint

[aleixac]

We have been talking that for security reasons (to avoid the User Enumeration issue) we would need to avoid the 400 response form the "/register" endpoint when the email is already registered. We think that, if the email and passwords submitted are correct, the response should be always 201 (unless there is an unexpected server problem), and what should change would be the email sent to the user when he tries to register with an already registered account vs. a new account:

• The new account registration mail should be the email verification one.
• The already registered account mail should be a different one, informing the user that the email is already registered in the system, and giving him access to the forgot password functionality.

More info about the User Enumeration issue: https://www.owasp.org/index.php?title=Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

[daffyDukk]

Hmm. The Register account feature is on the Plugin End so if you get a 400 status cant you just show a forgot password page? Where the user puts his/hers email in? And then gets an email for the reset process.

[aleixac]

That was my initial idea, but from the David's security point of view, he recommended me that the server should not answer different if the user exists or if it does not exists. As, with this situation, a bot could get information about user mails being registered at the system. But at the end it is our decision to protect the system from this security issue or not.