14

From what I understand it is bad security practice to display informative failed login messages like:

The email you entered does not exist

Instead of

Incorrect email/password combination

because it can lead to username enumeration. Is this is really an effective way to enumerate logins? It seems like the only way you could exploit this would be to come up with a massive list of millions of email addresses and then see if any have accounts. Considering the number of email addresses out there this seems like a long shot. Are there real world examples of this type of flaw being exploited?

Luc
  • 31,973
  • 8
  • 71
  • 135
Abe Miessler
  • 8,155
  • 10
  • 44
  • 72

4 Answers4

15

Let me give you an example of a hypothetical yet very plausible scenario.

There is an aspiring hacker named Bob. One fine sunny morning, Bob found an SQL injection flaw in a popular social networking site named HandBook. Using said SQL injection flaw, Bob managed to dump the a list of email addresses and passwords of accounts registered with HandBook. Given that HandBook has a shitty security team, all the passwords are hashed unsalted with MD5. Cracking open his trusty rainbow table, Bob manages to recover the plaintext passwords of 86% of the user accounts.

What does Bob do next? Bob knows that 86% of the people on HandBook are teenagers. What do teenagers love more than one social networking site? Two social networking sites of course! Bob decides to try out all the email address and passwords combinations he managed to crack against the authentication service of a second popular social networking site, Chatter. Given that teenagers are teenagers, they do not have strong password policies. Bob manages to access 76% of the user accounts simply by trying the same password or a close variant. He was able to accomplish this very quickly since Chatter's login form kindly notified him when he was trying to login with a non-existent email address.

Is this a flaw? Yes, potentially. I mentioned this in another one of my answers. It has been pointed out that this might not be a major issue if the usernames of registered accounts can be enumerated in another fashion, for example through the registration page. However, many registration pages are protected with CAPTCHA, which makes automated attempts against it that much harder.

  • 7
    Wouldn't the results of this be nearly the same assuming similar passwords and a less specific failure? True Bob gets some feedback immediately whether a user email exists or not, but how much does he lose reattempting any rejections with similar passwords without this knowledge? – Mr.Mindor Sep 24 '13 at 21:35
10

This is old lore.

In older times, people were using mainframes and very poor passwords, so protecting account names was "important": if an attacker knew the name of an actual user, then he could try passwords, and, at that time, trying a few dozen passwords tended to work.

Of course, this was unsatisfactory, because user names are not really secret information. It was much better to have strong passwords.

Nowadays, hiding user names is less important, and also impossible in some contexts. For instance, when a user registers on some Web site, using a "name" of his choosing, then the Web site MUST warn him about duplicates, and that's unavoidable; the site cannot tolerate two users with the same name. In that context, it is not feasible to really hide user names; thus, hiding user names had better be pointless. As @Terry mentions, CAPTCHA on registration pages may make user name enumeration harder to do automatically (but "harder" is not the same as "hard").

So failed login messages which do not distinguish between a non-existent login name, and a bad password, are still in wide usage, but more for the sake of tradition than for a strongly rational reason.


Note, though, that there are botnets out there which try to replicate by trying SSH logins on random IP addresses, with "common user names and passwords". Just inspect the auth.log file of a Linux server, you'll see these attempts. Such botnets have done that for years. They might do this out of a sense of Tradition (there is no reason to believe that evil people are more competent at what they do than non-evil people), but it is possible that this kind of brute force really works with a non-negligible success probability; and a failure message which makes a distinction between a bad login name and a bad password can only help these botnets.

Therefore, while the whole notion of avoiding to leak user names is mostly an historical remnant from older times, it can still have some value in some corner cases, mainly mass-brute-force by a mindless attacker.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • How about cases where usernames are assigned, and not user-changeable? For those scenarios, unregistered (or even registered) users will not naturally have access to any process that has a need to check for, and alert the user to, "duplicate user names". Such situations would be much more common to corporate networks than public social media sites, but are still very relevant. – Iszi Sep 24 '13 at 16:22
  • 4
    It is avoidable on registration: Step 1 of a registration wizard asks the user for their email address (which is their username to log in). The response would say "we have sent you an email, please follow the instructions in there" in either case of the user being registered or not. The email would contain a link to continue registration if not registered, or contain a link to reset the password if registered. This is classed as an "out of band" message and is the most secure way of accomplishing this. – SilverlightFox Sep 25 '13 at 09:35
3

If an attacker is doing a social engineering attack. The attacker could put a victim email address inside the login form. Then we will be able to know if the victim is registered or not under a specific email. If the victim is registered to a web site, the attacker would create an account on that web site and he would try a social engineering attack. I don't think it will stop the attacker but by not giving the message "The email you entered does not exist", it should slow down the attack.

fvaliquette
  • 121
  • 4
0

GDPR changed the take on this one a bit. If you leak that someone is having an account on your site, you are now leaking PII (Personally Identifiable Information) about that person and if that someone is an EU resident, potentially exposing you to fines.

Bruno Rohée
  • 5,221
  • 28
  • 39