Disclose to user if account exists?

Question

Someone told me it shouldn't be possible for someone to detect if a certain email address is used by a registered user on a website. So, for instance, when the user asks to reset his password, you should say "Password sent" whether the email exists in the database or not. If not, people can use this function to check who is a member and also check validity of spam lists, etc.

But I noticed that Facebook says "E-mail already registered" if you try to register the same e-mail twice. Does this mean that conventions have changed; that informing the user is more important than revealing accounts?

Answer 1

It is a rather old tradition not to tell people whether specific logins exist or not. This is why Unix or Windows systems, when asking for user credentials, will respond to any error with a generic "wrong username or password" message. The idea comes from a rather old-fashioned vision of attacks: envision a bad guy who wants to enter a mainframe, and succeeds in getting his hands on a serial terminal plugged to the system, or maybe a telnet interface over a modem line. This attacker will be in a position of an online dictionary attack: he will try to guess a pair login+password which grants access. The administrative login names like "root" were usually better protected than normal user accounts (the "root" user was better at selecting strong passwords, or at least so it was surmised) so attackers would try to find normal user accounts, and, in particular, normal user account names.

Watching the movie War Games (from 1983) gives you a good idea of how things were.

Note the critical point: in the attack scenario above, the attacker wants to obtain at least an account, but could not get one under normal conditions, or even know who has an account.

It is now 2013, three decades after that movie. We have servers where everybody can register for free, and get an account. Obtaining one account is thus no longer an attacker's goal. Instead, the attacker will want to access specific accounts, with known identities. This is not the same situation. The context has changed. Therefore, old lore is not necessarily applicable.

---

Anyway, when a user tries to register on Facebook, he expects the process to work. At that point, the process may fail for only one plausible reason, which is an email address already used. It would be difficult to hide that fact from the user...

If we want to "protect" user email addresses, then the registration process must go thus:

• User enters his alleged email.
• An email is sent to that address, containing a one-time registration link; however, if the email is already registered, then an email is sent explaining that fact. No clue is written on the response Web page as to whether the email already existed in the system or not.
• The user registers by following the link from the email.

Such a process would double as an email verification process, so that's kind of good. However, it has some latency (user must get out of the Web site, open his email reader, and wait for the incoming email), so this can be problematic for shopping sites (users are not patient, and they are prone to go shop elsewhere if they find the checkout process too cumbersome). Also, there must be some guardrails to avoid this registration system to be abused into a spamming machine.

---

I think it can be said that, for Facebook maintainers, making the registration process as smooth and quick as possible is more important than the user's privacy. Really, who would that surprise ?

Answer 2

There might be PII risks involved to consider. It is safe to assume that 'everyone' has a Facebook account, therefore disclosing that any one particular email has registered is not a big deal.

But, take another service, like 'depression-help.com' or 'it-burns-when-I-tinkle.net'. It would be a problem to release to the general public that a particular person/email is registered with the site.

Also, for small services with an intentionally small userbase, disclosing usernames can provide additional info to an attacker that could compromise accounts just like that certain 1983 movie.

Hat-tip to @ThomasPornin, but I believe there are some cases, like these that I have suggested, that make it worthwhile to make an informed decision about not disclosing user account names/emails.

Answer 3

There really isn't a graceful way to solve this problem that can make everyone 100% happy. If you force the use of email addresses as usernames, you make it easy to determine whether somebody who has a given email address is a user (privacy problem). If you allow arbitrary usernames, you really can't get around eventually revealing whether or not a given username is already in use, and all you can really do is take steps to slow down a user who's trying to discover valid usernames.

New user registrations are the toughest problem to deal with, because there's no getting around the fact that eventually, you're going to have to gracefully deal with a username collision. Here's one possible option: Have the user enter an email address, a proposed username, and the desired password. Upon submit, validate that the password is acceptable, and email the user a validation URL.

• If the email address is already in use, but associated with a different username, email that user, remind him that he already has an account, and ask whether he'd like to reset the password.

• If the email address isn't already in use, but the username is, email the user an error message letting him know that he needs to pick a different username, and has to wait an increasing amount of time between each attempt.

• If the email address and username are both new, email the user a confirmation link that requires re-authenticating with the new username and password before making it official.

• DO NOT allow two users to have the same username on the assumption that you can identify one or the other based upon their passwords. Among other things, if two users can share the same username, that means you can never lock out the username due to failed login attempts without affecting BOTH users. And god forbid, if they ever DO happen to somehow pick the same password someday, all hell will break loose.

• Don't use the same value for username and public identity. You don't necessarily have to actively prevent users from entering the same value for both if they really WANT to, but the default should be to allow users (on something like a message forum, for instance) to have a public nickname that doesn't necessarily have anything to do with the username they log in with.

• Don't sequentially assign user IDs. Use at least 31, preferably 62, bit random values that are generated and verified as unique at registration time. The nice thing about 31 and 62 bit values is the fact that they neatly translate into 6 and 12-character base36 strings. When debugging, it's a lot easier to remember a 6 or 12-character string of lowercase letters and digits than a 6-17 digit decimal value. The hardest part is responding to requests that specify an invalid user ID with responses that are fake, but can't be readily distinguished from real user ID responses by algorithmic means.

Remember: you can not, and will not, ever succeed 100% at stopping an attacker from occasionally verifying whether or not a given user ID or username is valid. Your goal is to make it as slow and expensive as possible, without unreasonably burdening your real users. For a real-world analogue, think about DVD and Blu-Ray region codes. Back when a player cost $500+, region codes were an effective way to stop almost everybody from playing movies purchased from another region. Now that you can buy a Blu-Ray player for $80, and a HDMI selector for $20 and get change back, there's really nothing to stop a film buff from just buying two or three Blu-Ray players (one per desired region), stacking them up, and running them through the HDMI switch.

For routine logins, be purposefully vague about the reason why THIS login attempt failed, but be equally up-front about the possible reasons... and give them concrete contact information of somebody who can assist them. Keep track of failed logins, and lock out the account if too many failed login attempts are made.

• Don't tell them outright that the account has just gotten locked out, or is currently locked out... but don't be shy about mentioning it as one of several possible reasons why a login attempt might have failed. Keeping the fact that an account MIGHT be locked out from a user attempting to log in will do nothing to help your security.

• You don't necessarily have to lock out an account semi-permanently due to failed login attempts. In many cases, you probably shouldn't, because THEN you'll have created a handy denial of service attack. If an account has too many unsuccessful login attempts, you COULD do a "soft" lockout for 1, 6, or 24 hours, at which point the lock will remove itself. This is the one scenario IMHO where it's legitimate to tell a user to "try again later".

An example error message that might be displayed when a login attempt fails:

The username and/or password you entered was not accepted. You might have entered an invalid username, used an incorrect password, or attempted to log in with an account that has been locked out due to excessive failed login attempts. If the account has been locked out, you can contact ___ for assistance[, or wait _ hours for the account to unlock on its own]. Please note that this error message will be the same for all failed logins, regardless of reason.

DO NOT tell them "Something went wrong, please try again later" unless the problem will literally fix itself on its own. It won't fool an attacker, and will seriously annoy legitimate users. This is one of my ultimate pet peeves, and near the top of my list of "horrible things developers do in the name of security theater". Aside from being incredibly annoying, if somebody's account has been compromised, the LAST thing you want them to do is wait until later before bringing it to somebody's attention.

Answer 4

It's standard facebook behavior that you can seek a account if you have the corresponding email address. These days plenty of people have deactivated that option but that's still the place facebook is coming form.

When doing forum moderation I frequently used that feature to gather information about whether a newly registered account is a registered account of a banned user.

Websites giving away whether email addresses or usernames are real is a way to attack anonymity. I remember a case where someone reregistered who was using the IP of a TOR exit node. I was able to tell the person the name of his mother through information that he shared on facebook. The way to the information went through four hoops of nicknames that were associated to each other.

Disclosure of information like this makes it easier for companies like http://www.spokeo.com/ to operate.

When it comes to protecting privacy you should also consider all data sensitive. Take a forum with 1000 users. Users post harmless information under an nickname. A user logged into the forum with an email address that's associated with his real identity.

With 1000 users there a good chance that I can identify with stylometry and disclosed information which of the 1000 users is the person I'm searching. If I succeed in that task I got a secret nickname.

I can now run google searches on that nickname and also search for nickname@gmail.com in other databases. I also got a larger text sample to make it easier to run future stylometry attacks.

A government level attacker that wants to find dissidents has the resources to query a lot of webservices to check whether certain email addresses exist can also invest into good stylometry systems.

If you want to protect privacy then it makes sense to hide email addresses that are registered.