Having a consistent "don't reveal email addresses of members" policy

Question

Developers are dogmatic on having "invalid username or password" on login screens; our applications should not reveal if somebody is a member given an email address.

But there are two other ways our application can reveal a member:

1. the signup page returns a "this email was registered by somebody else" (often this is a dedicated endpoint for Ajax)
2. the reset password page has a "your link has been sent to your email" or "provided email does not exist in our records"

Why are we only worried about the login screen revealing membership? Should we plug these holes as well?

---

The "provided email does not exist in our records" on reset password page is useful when we have entered a wrong email or we signed up with wrong email address. Example: I am named Raj, have wrongly signed up with ral@example.com (mispelled J) and I try to send a reset request to raj@example.com.

Answer 1

If this is supposed to be a secure system to that extent and since the email address is disclosed elsewhere, the developers could make the username a randomly generated number instead of the user's email address. This closes the information leakage gap.

For instance, for a generated numerical username:

• Failed login: "Username incorrect"
• Failed password: "Password incorrect"
• Already registered: This error won't occur with a surrogate username key unless you have a company policy that people (e.g. in a family) can't use the same email address.
• Password reset (by username): Email address isn't disclosed as message can say "Reset link has been sent to the email address associated with this username."
• Password reset (by email address): "Reset link has been sent to this email address for all accounts that are associated with this email address."

Besides, the either/or fallacy of login field validation adds only a few bits of extra entropy to the overall brute force security whilst decreasing usability. Just increase the minimum password length requirements to gain the same effect sensibly. One assumes that exponential delay exists on the password attempts in any case.

Answer 2

There is usually a trade-off between security and usability. As a web developer, you have to decide what level of security is required for your application and strike a balance between the two.

As correctly pointed out by you, there is an inconsistent treatment on the protection of email addresses on many websites. The reason is fairly simple:

• A login page requires only an email address and password, which makes it pretty easy to make several attempts in a short time.
• A signup page takes a greater amount of time to fill in manually.
• It is possible to implement CAPTCHA on both password reset page and signup page to prevent automated enumeration of email addresses.

By hiding the fact that an email address is already taken up (on registration), or that an email address is wrong (on password reset), the consequence is that legitimate users who make a typing mistake are not able to sign up, or reset their password and they wouldn't know what is the problem. The cost is either you lose a customer or it increases the workload of your help desk, and adds frustration to your users.

In the case of showing a generic login error, as long as the email address remains on screen after a failed attempt, it is not difficult to tell whether the email address or password is entered wrongly. The inconvenience of not being told which is wrong is quite inconsequential.

If your security requirement is so high that email addresses must be kept a secret, then it should never be used in your authentication system. Try usernames instead.