On my website's account creation form, how to avoid leaking the information that an email address already has an account? [duplicate]

Question

It seems common practice, when denying access to a user because of an incorrect email / password combination, to not specify which of the username or password was incorrect. This avoids leaking the information that an account does or doesn't exist with that email address.

For instance, if I try to log in with my spouse's email address on a dating website, and the error message is "Incorrect password" rather than "There is no account with this email address", I can draw the necessary conclusions.

But how do I avoid that same information leak on an account creation form, where I must prevent a user from creating an account with an email adress that already has one?

Answer 1

I'm probably stupid and don't understand the issue, but to me it looks like the problem can easily be avoided by providing the necessary information only via email (which an attacker isn't supposed to be able to access). If you don't want to leak any information, then the public messages must not be distinguishable, whether an email is already been used or not. If you really want to be careful, technically, you should also make sure that the response time is the same, to avoid timing attacks. But this, depending on your needs, might be overkill.

So what happens is:

• If the email has not been used yet, you display a message like "Thanks for registering, now go check your email to complete the process". The email will contain a link to validate the address, and when the user clicks it the account will be created and enabled. You can also create the account at once, before validation, but you will need to make sure an attacker cannot check if it's been created or not (otherwise that's information that is leaking).

• If the email has already been used, then you display the same message (see the point above), for example "Thanks for registering, now go check your email to complete the process". This way an attacker will not gain any additional information. Is the email address already been used or not? The attacker can't know, unless they can read the email. But the user will know, because the message you will send via email this time is different, and it might be like: "You just tried registering at example.com with this email address, but you already have an account connected to this email address. Did you forget the password? Blah blah blah. If it wasn't you, just discard this mesage".

As a result, an attacker will not be able to understand if an account has been registered with a specific email address, unless they have access to that email address. A user, instead, since they supposedly have access to the email address, will be able to get all the information they need, whether they signed up correctly or they tried to sign up twice.

Answer 2

An idea I have: on the creation form, only ask for an email address. Upon submission, immediately send an email to that address, including a link to a page which allows the user to choose / reset their password.

On the page, display a message like "An email has been sent to your address in order to verify your account or reset your password."

First password choice and password reset are essentially the same thing, and verifying the email address is necessary anyway.

Answer 3

This is a bigger question then it might seem. I'll try an focus on the privacy aspect, rather then the engineering aspect.

This scenario isn't entirely implausible, given the Ashley Madison leaks, and the repercussions individuals and/or companies received.

The core issues here are:

1. How do I provide a secure experience, without some semi-unique publicly identifiable information?
2. Can I offer users some level of plausible deniability?
3. In the very likely scenario of password recovery, how do I handle this with some level of privacy?

For the purposes of this question, I will continue with the understanding that we are:

• Attempting to mitigate casual or widespread "outing"
• Preventing the linking of user information to a real human being

The difficult part is that an account by nature usually needs to be unique, and tied to someone. Additionally, it needs to be secured with something like a password to keep conversations private ("something you know").

To add some additional protection, allow only those WITH an account to query for other users. All services and functionality are hidden behind a login screen. How you decide to implement registration is a separate issue. This idea is implemented on several services already, but it is unclear how effective it is. You would also have to avoid listing account creation date/time anywhere. This satisfies points 2 and 3, without dealing with 1.

Easiest thing would be to force a user not to use a public email service or phone number. Again, how this is implemented is a software engineering question. You will have to deal with bots or users who wish to abuse the platform. This satisfies points 1 and 3, unlikely 2 as well.

Taking an idea from how apps/users work in censorship central China, assign each user a "random" ID. These could be 8-12 digits long so they are both unique enough but also rememberable. Having a copy of this ID anywhere besides the user's brain and the database can enable linking the two, defeating any privacy gained. This means no emails, no phone calls, no "selfies", or anything of the sorts. Users can assign themselves a public facing name when changed by the user at any time, points to a generic "doesn't exist" page.

To gain some level of plausible deniability, you can have a "no sign up" process. Users could have multiple accounts tied to an email address or phone number without a verification process in place. Each time someone wishes to "register", a random ID is assigned and only displayed once. From there on to access that account, you provide the "secret" ID and a password. The system will let you register a set number of accounts per an email address or phone number, but more than the usual 1 to 1 mapping. These last two paragraphs satisfy points 1 and 2, but not 3.

Answer 4

This is a very good question. In my opinion we need to clarify what you use in order to identify a user. Is it an email address, a username that the user selects or a username you give to your user. Each of the above must be handled differently. If you use as email as account identification then the data leak is a lot more important. Remember email is considered sensitive data. This could result in your application leaking the email address from users. If a username is used then the leak is not that important in my opinion as the user usually uses an alias that is not considered sensitive data and there is no real privacy issue.

Having said that the problem still exist if in the registration process you inform the attacker that An account already exist with this username you give the attacker a small hint, that his efforts to fish or brute force the password of the user is not for nothing.

So what can we do?
My personal suggestion is to require 3 fields username, email, password .Both the username and email address should be unique. Which means there cannot be the same username more than one time in the database. Same for the email. This way you can have a only one user using the username = bill and the only a user with email=bill@some_domain.com

• Examples
  Let's say there already exists a user with the following credentials.
  Username=bill + email= bill@some_domain.com
  The bellow combinations should all be invalid.

1. Username=other_username + email= bill@some_domain.com
   • Message --> username or email invalid
2. Username=bill + email= other_user@some_domain.com
   • Message --> username or email invalid
3. Username=bill + email= bill@some_domain.com
   • Message --> username or email invalid

When the user will try to login only one of the 2 values should be enough to enter + the password. In your database the username filed could look something like this: system_username = username+email for example: system_username = bill,bill@some_domain.com * (This could result in performance issues)

• How to mitigate If it's to much trouble or more the current schema of the database does not allow for such a change, then apply the same principals ass on the login part.

1. Let some time pass before the registration will complete. (Brute force will take more time)
2. Limit the create account requests . And more..

(Edit: As pointed out by nobody in a comment bellow, there is a problem with this solution when a big random username is entered.)