I noticed that the new gmail login asks for username first, and then confirms if such username exists, before asking for password input.

Does this not go against conventional security wisdom to not divulge information about whether an username exists, to thwart the class of attacks that tries many possible usernames?

I assume Google knows what they are doing, so does this mean they have some way to be secure against what is conventionally considered a vulnerability?

  • 87
    Does trying to register with some username not reveal the same information?
    – DrLecter
    Commented May 8, 2015 at 16:30
  • 11
    In case of an email provider I believe it's already possible to numerate usernames by emailing them and looking at which ones get delivered (even if flagged as spam) and which ones bounce, so it's a bit less of an issue.
    – user42178
    Commented May 8, 2015 at 20:50
  • 13
    Connect through telnet to gmail and try sending a mail to a random ID. You will easily know if that ID exists or not. There are many other similar ways to know the existence of IDs.
    – shivams
    Commented May 9, 2015 at 0:38
  • 6
    This "conventional wisdom" is from a usability viewpoint utter idiocy -- I have to remember which of my 4 or 5 email addresses I've used and try every variation of my ten-or-so passwords to login? Well, I have better things to do than try to login 50 times so I'll just have to reset my password again... Commented May 9, 2015 at 17:23
  • 8
    Completely agree with Steve. There needs to be more consideration of the usability aspects of security. Without it, users make bad security decisions to make their life easier. Our systems should make their life easier to help them make good security decisions! My other frustration with systems like this is not repeating the password rules (length, accepted characters etc) at login; it's public information (on sign up), so why make the user hunt around for it?
    – Rikki
    Commented May 11, 2015 at 12:52

10 Answers 10


For smaller sites, you don't want to allow hackers to enumerate your user lists, but for Google, the site is so large, one can assume almost everyone has an account or several accounts. So, the risk is minimized after a threshold of ubiquity.

It is still a good idea for most sites to not disclose whether a username exists, but the risk needs to be weighed against the new user registration process. What you want to prevent is an automated process from enumerating your lists. The new user registration process should include some form of delay or gate so that a script can't rapidly try a dictionary of users. This is often achieved by sending an email with the results of the un/successful registration process. Yes, one could still enumerate, but there is a delay and an additional step.

Another thing to consider is the difference between a public site and a private site. Google is a public service an usernames are also public (disclosed with every email sent by an account). On the other hand, an internal corporate site, where only current employees can access, is private, and requires more stringent controls to prevent enumeration.

  • 1
    Actually, usernames are not disclosed in email addresses. An email address could appear as [email protected] but that user's username could be [email protected]. With Gmail, dots are immaterial in email addresses, but crucial in validating login ids. Commented May 9, 2015 at 12:35
  • 27
    @AndrewLeach Google lets me log in if I leave out the dots, they seem to be parsed out for logon as well.
    – Eric G
    Commented May 9, 2015 at 16:27
  • 1
    That's changed, then; they used to make a point of the difference. Perhaps people couldn't cope with it being different. It seemed reasonable to me, and I don't recall an announcement about the change (but then I don't suppose they would announce a reduction in security, even if it's only security by obscurity in the first place.) Commented May 9, 2015 at 17:16
  • 2
    When dealing with login forms, hiding whether a user's username / email address is correct also makes it exponentially hard for users to remember which password they used on the site. Commented May 9, 2015 at 17:24
  • 2
    It's surely also possible that they check (so far as possible) for such automated enumeration? If a 'user' tries more than some (quite low) number of usernames, it'd be a fair bet they're not a genuine user.
    – OJFord
    Commented May 10, 2015 at 2:26

Jeff Atwood, when making the login for Discourse, had this to say on the subject:

This was the source of a long discussion at Discourse about whether it made sense to reveal to the user, when they enter an email address in the "forgot password" form, whether we have that email address on file. On many websites, here's the sort of message you'll see after entering an email address in the forgot password form:

If an account matches [email protected], you should receive an email with instructions on how to reset your password shortly.

Note the coy "if" there, which is a hedge against all the security implications of revealing whether a given email address exists on the site just by typing it into the forgot password form.

We're deadly serious about picking safe defaults for Discourse, so out of the box you won't get exploited or abused or overrun with spammers. But after experiencing the real world "which email did we use here again?" login state on dozens of Discourse instances ourselves, we realized that, in this specific case, being user friendly is way more important than being secure.

  • 6
    Very interesting conclusion. Basically, they would rather cope automatically with users who can't remember which login name they used, than keep their user list secure from brute forcing. I can't speak for them, but it sounds more like they are saying "minimizing support volume is way more important than being secure."
    – Jeff Meden
    Commented May 8, 2015 at 20:40
  • 7
    Lowering support volume is also (usually) more user friendly -- being hard enough to use that a significant number of users need to contact support is the opposite of good usability.
    – Johnny
    Commented May 9, 2015 at 0:10
  • 33
    Security is not about applying arbitrary rules and best practices. It is about understanding how all of your controls and countermeasures work together and the relative value, in consideration of providing the actual service. The risk value of username enumeration goes down if you have mitigating controls that address the usefulness of knowing the username (e.g., IP address monitoring for attempted logon, failed attempt lockouts, blacklisting attackers, etc.)
    – Eric G
    Commented May 9, 2015 at 16:25
  • 2
    @JeffMeden see Tom Leek's answer here - the "security" provided by hiding usernames is minimal at best.
    – Jason
    Commented May 12, 2015 at 18:13

For Gmail, you can determine whether an account exists simply by sending an email to an @gmail.com address. If it bounces, that account does not exist.

This is true of many email providers. Here, usernames are not considered secret. If a user has the email address [email protected] everybody knows that foo has an account at example.com with username [email protected].

However, for most other systems it is a breach of privacy to reveal usernames. If someone can discover that [email protected] has an account at nostringsattacheddating.example.org and Bob's wife Alice can try registering with the username [email protected] on the website and it tells them the username is already in use then it is a massive breach of privacy.

Remember that email address has its roots at the email provider. There is no privacy lost if [email protected] is known to have an account at example.com, as there is no point of reference for who [email protected] is. The same isn't true for another system using email as the username - a user with username [email protected] on a non-email website will be the same [email protected] as registered at other websites. There is privacy to protect about which accounts Mallory has.

Also, revealing usernames can be useful to an attacker. This is known as a username enumeration vulnerability. If an attacker knows which usernames exist, then they can run a password guessing attack.

As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will.

It also allows attackers to target users of the system via phishing.

It is easily possible to design a system where user enumeration cannot be executed. For example, the sign-up and forgotten password processes are one and the same.

The steps are:

  1. The system asks for their username (email) on a single page, with no other input fields.
  2. When the form is submitted the system asks the user to check their email account.
  3. If the account exists, the email contains a password reset link.
  4. If the account does not exist, the email contains a sign-up link.

As a bonus, you've validated their email address at sign-up in case they need to reset their password at a later date. Any typos will mean the user can't sign up at all - which is good because a user isn't accidentally using an account registered to a different email address.

Both the password and sign-up links contain a cryptographically secure random ID, so they cannot be followed without receiving the email. Only someone with access to the account can find out whether a username is registered or not (Bob better keep his email and laptop passwords secret from Alice - it would be wise for him to turn off any notification sounds in case Alice tries this process when they're in the same room too).

See some of my other answers for related topics:

  • "For Gmail, you can determine whether an account exists simply by sending an email": this isn't true in general. If you send too many emails to non-existing addresses, you'll get blocked.
    – Nemo
    Commented Aug 2, 2016 at 20:52

I'm sure that rule developed in the days of 'big iron', when all accounts were on big corporate or government systems. Since the system doled out the account names, the use of a sign-up page to look for account names wasn't an issue. Thus, keeping the list of account names was feasible & useful.

Now that we're dealing with self-sign-up sites, it is impossible to keep the account name list secret. Plus, so many people these days make their account name public anyway. Under these conditions, it's pointless to try to hide the fact the it was the name that failed instead of the password.


There's a more important reason for prompting for username first and then prompting for password: it allows Google to offer a different UI for accounts that are using passwordless authentication or other experimental login mechanisms without revealing beforehand which accounts are using it.

It's similar to how Google's 2Factor auth UI isn't displayed until after the password is entered: an attacker won't even know that a second factor is involved until after cracking the first factor.

Combined with what other answers are saying here about the relative non-risk of leaking usernames, this seems to me to be actually a security improvement.


Knowing which username exists or not is not important, because an attacker can also check it from the sign up page. Google does not allow that an attacker runs an attack like brute force attack for obtaining a username list.

  • So basically the rule "don't return 'user doesn't exist' at login" is a myth? Did it ever make a security difference?
    – ataftoti
    Commented May 8, 2015 at 18:22
  • 4
    It does make a security difference. For example, I have a Jira instance that people log into. I created the accounts for my team, it isnt self sign up. Thus, the only way to disclose the username is through the signup process. It all comes down to usability tradeoffs. On public sites, there often exists a need to tell people if a username exists or not, but that doesn't mean that exposing that information isn't a risk. Designers should understand what they are exposing and put other technical limits to ensure it can't lead to widespread abuse.
    – amccormack
    Commented May 8, 2015 at 18:58
  • 1
    The ability to check from a sign uppage is not universal. The best practice is to say an email has been sent to that address even if it already exists and alert the person that someone tried to sign up again with their account or just don't send out the email again. Also, its important to distinguish between and email address and a user account. A user account on something like Internet banking is usually not public and should be protected versus something which by definition must be public.
    – Eric G
    Commented May 9, 2015 at 16:23
  • 2
    This "conventional wisdom" is security-theater mostly. Commented May 10, 2015 at 5:20

Email addresses are not the same as usernames. A username is semi-private information (potentially), but an email address is publicly disclosable and publicly routeable. Think about postal mail, the mailing address if often well known, but the current list of valid recipients is not necessarily design to be public, although there are often ways to look that up online as well. In the case of something like Google, they have Google+, YouTube, Google Groups, etc. which make many of the addresses already well known.

It's also trivial to query an email server and determine if a given email address exists, using telnet or many websites will do it for you. There is little to gain from protecting information which is easily accessible in other ways. This is why some sites separate the email address for the username. In the case of an email provider, it doesn't really make sense to have a different logon name and then email address for the average user (maybe those of us who are more security paranoid would like that feature).

Switching to a two-step logon reduces the likelihood that a user's password will be entered into a search field or the username field. These fields are often logged and the logs get correlated all over the place and are less likely to be secured. So if the logs are attacked by a hacker or nation state, then the attacker may be able to correlate the IP address from the user with their username and then notice something like "m7p@55w0rd!!!!" which sticks out and assume its a password.

In terms of risk management, the risk of password exposure is much greater than the risk of username enumeration. Google likely has more robust anti-fraud and anomaly tracking to deal with the risks associated with known usernames.

I think a good way to understand this is the Tire Swing example in the FAIR introduction (pdf). The risk calculation of a known username is impacted by the other controls and factors. Do you stop brute force attacks, require multi-factor authentication, how else could this information be obtained? In the scenario, effectively you are trading off between a risk that you have control over (monitoring of all logins) versus something on the old form which is harder to control (password being typed by user into the wrong area).


I'm going to go out on a limb and say they likely have some mechanisms in place to ensure it isn't an open repository of users.

We implemented a similar system on our little site using a redis backed solution.

Users are initially presented with a simple email/pass with a button for login and register. Upon entering their email and moving on it's checked for a match and if matched the register button is removed. If not they are presented with the full register form.

We track the number of attempts by ip subnet and blacklist after a given threshold. Blacklisting doesn't impact their ability to use the site, it simply reverts to the standard behavior of login/register options.

  • 1
    A spammer who wants to build an account list can rent a botnet to get around blocking by IP subnet.
    – Christian
    Commented May 9, 2015 at 10:09
  • 1
    True. That being said if Google wanted to (though other answers suggest plenty of valid reason why they may not care) they could employ other abuse prevention mechanisms. For instance tracking deviations from standard failure rates and reverting behavior globally Commented May 11, 2015 at 1:42

Yes, they have systems in place to prevent abuse. Google has extensive "anomaly detection" mechanisms, which serve errors or captchas when your activity is suspicious: the best known examples are blocks from Google search and the NoCaptcha ReCaptcha.

The fact that you were allowed to know whether that account exists doesn't mean that everyone would nor that you would be able to actually guess anyone else's username. Try and let us know how long before you're blocked, it's an interesting test.


Pretty much everyone is already doing this

I noticed that the new gmail login asks for username first, and then confirms if such username exists, before asking for password input.

Google already has this feature. When you try to sign up for a new Google account, it has to check to see if the username already exists or not.

Does this not go against conventional security wisdom to not divulge information about whether an username exists, to thwart the class of attacks that tries many possible usernames?

If they didn't check, how would you properly authenticate? Multiple people with the same username is bad news bears for the integrity of the website. Of course, in many cases, you could use unique email addresses, and allow multiple people to have the same names.

Like I said before, pretty much everyone is already doing this in some way. There is nothing to worry about here. If you want to slow down mass enumeration of usernames, just include a captcha after a few attempts.

Captchas can't really prevent mass-mailing tricks

Spammers frequently send out large amounts of spam to e-mail addresses. While Google may shove the email into the spam folder, that doesn't prevent enumeration through non-bouncing emails.

It's trivial to create a mass-mailer which uses thousands of different IP addresses, and then attempting to enumerate by not receiving a bounced email. You could even send random garbage. Remember, if your goal is to verify whether an email address exists or not, it will suffice to not receive an error email after a few days.

  • 1
    They're "already doing this" since Google started. Before Google, few did.
    – Nemo
    Commented Aug 13, 2018 at 18:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .