How can you prevent email addresses from being harvested from a registration form?

Question

When you go to a website's login form and enter the wrong credentials, the website can give you one of three error messages:

1. Your email is wrong

2. Your password is wrong

3. Your email or password is wrong

I've read that the safest practice is to only show the third error message, because it prevents malicious users from using the login form to find out which emails are already in your database. If they're able to learn that information on a large scale, they can sell off the email addresses to spammers or try to log in as those users.

In addition to the login form, there are two other common ways of discovering valid emails.

The forgotten password form on a website allows you to enter your email and have a password reset link sent to your email address. If you enter a non-existent email into the form, the website can give you one of two messages:

1. That email does not exist

2. A password reset link was sent to your email address, if it exists

For the same reason, the best security practice here is to only show the second message, even if that email doesn't exist.

The user account registration form allows you to create a new account on the website. It requires you to enter several pieces of information, like an email address and a password.

If you try to sign up with an email address that is already being used by another account, the website can tell you that the email address is already in use.

Many large websites, including Stack Exchange, do it that way, even though it causes the same problems that are listed above.

Here are my questions, which are both related to that problem:

1. How can a website allow users to register without leaking the email addresses of their other users?

2. Is there any benefit to correctly handling the login forms and forgotten password forms if the registration form has this problem? In other words, if you can already get everybody's email addresses from the registration form, aren't the protections on the other two forms just a pointless nuisance to the end users?

Answer 1

The email harvesting scenario you describe is really slow and not likely to happen, at least as a way to gather lots of email addresses. The attacker would need to brute force really long strings against your form. As already stated by symcbean, emails are already very cheap if you buy them and it's pretty easy to block such attempts if someone tries to use this form repeatedly.

The standard way of gathering emails is by using tools like theharvester to quickly gather all mails associated with a domain (for example a company).

In case of password reset, you already answered part of your question yourself, you should always just return neutral feedback and if you want, implement a blocking mechanism which blocks an IP after too many attempts to register / reset.

If someone wants to register, you can:

• first ask for his registration mail
• then send a registration link to the mail
• the further registration process will then continue from the link

This way it's not possible to guess if an email is already registered.

Answer 2

AdHominem is right; using email verification prevents this attack vector. It's a usability challenge, though. I think that for many sites the right (but cumbersome) way to do it is as follows:

1. Allow the user to complete the entire signup process and start using the site with a low-privilege, temporary account. You should probably prevent them from taking any actions that are publicly associated with the account (e.g., posting to a forum).
2. If the email address was new, send it an email allowing them to verify the account and link it to that email.
3. If the email address was already registered, send them a reminder / password reset link and tell them to follow it if they need to access their existing account.

This can be messy, especially if you do allow the temp account to take any actions that the user might want re-assigned to their existing account once they unlock it. The easiest way would be to prevent the user from doing anything until verifying their email address. But I suspect that forcing them to switch to their mail client and possibly wait several minutes reduces signup rates, which is why many sites repeatedly ask for, but do not require, email verification.

Another possibility is that if someone signs up with an email address that currently exists you:

1. Create their account and show it as using the requested email address, but don't actually link it to that address (i.e., don't use it for password resets or email announcements). An attacker won't be able to tell the difference, because they can't check the address.
2. Email that address with instructions for resetting the password on their existing account and letting them know the consequences of having a duplicate account that can't receive email.
3. Never do anything else about it.

These scenarios assume that you're only using emails for contact between the site administrator and the user. If you're using them for another purpose, such as enforcing uniqueness or displaying a verified email address to other site users, then you do need to go with an email-verification-first approach.

Answer 3

Instead we could just use in a username in the login form without leaking the registered email, and send an alert to the users in case there is a failed login attempt to their account to warn them that there is someone who wants to connect...

Giving such information/clues will just make brute force easier for an attacker, for example if I give to a website (you will find that for wordpress) the login admin and an arbitrary password it will answer me with "the password is incorrect" so I could launch a brute force attack for the admin account....

Another solution you could ask for changing the email in registration form without giving the real reason like google does. Many usernames example alice.bob even if there doesn't exist or be registered it doesn't mean that is was taken by Mme Alice.Bob (many times I ask for a username for gmail and Google shows me the message that it is not available and proposes something like username1253, and if you check by sending emails or G+ you will not find them)