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?
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.
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.
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:
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:
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.
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.
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.
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.
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.
