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

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.

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.

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.