On two-step login forms, why is it the login name and not the password that's asked first?

Question

There are several login forms (e.g. Google's) on the internet where you first enter your login name and then, once that's submitted, you get to enter your password.

One of the advantages of this is, I suppose, that the server can pull up an image only it knows and display it to the user to help foil simple phishing schemes.

My question is why nobody does it the other way around - first ask for a password and then for the login name.

I can see the obvious answer (that the password might not be unique and therefore the server wouldn't know whose anti-phishing-images to display), but that doesn't convince me. Immediately disabling accounts which share passwords or at least forcing users to change their passwords to a unique string next time they log in might be ways around that and as an aside it would solve the "123456" password phenomenon.

Another issue I can see is that in a phishing scenario where a user enters his password correctly and then notices that the wrong images are displayed to him, he's already given up his password and all that remains for the phisher to do is to identify who this password belongs to.

What I'd like to know is whether the login-then-password sequence is mostly due to convention or user interface considerations or whether there are other security issues with reversing the sequence to ask for the password first (besides the two I've mentioned).

Answer 1

A lone password is not necessarily verifiable by itself. In particular, if the server does things properly, then it stores not the passwords themselves, but the output of a password hashing function computed over the password. A password hashing function (as opposed to a mere hash function) includes some extra features, including a salt (for very good security-related reasons). Verifying a password then requires knowledge of the corresponding salt. Since the salt is instance-specific (the point of the salt is that distinct users have their own salts), the user identity is required (the user identity is used as an indexing key for the salt).

Answer 2

For one thing the server would not know if the password alone matched any accounts.

In a secure system, passwords are salted and then hashed.

In a simplistic demo, suppose I had three users:

Username  Password
bob       foobar
alice     foobar
maggie    foobar

When these passwords are set, a salt is added and a hash is generated:

Username  Salt      Value to hash     Hash result
bob       ABCDEF    ABCDEFfoobar      778f9aab91717e420e447d7e4cdd84f1
alice     123456    123456foobar      17e9191daecc5b8be26779209769b275
maggie    ZXCVBN    ZXCVBNfoobar      527cb07b112559cf9c1aff19d28074fa

As you can see, the purpose of the salt is that no two passwords are stored the same, even though the password may match. This is an important security step to take to prevent rainbow tables being used on an extracted password list.

This makes it impossible to determine which account is being logged into on the basis of password alone, because the salt to use isn't known. This is because username is used as a key for the lookup, and without that being provided to the server, the password entered at step one cannot be matched without trying each hash in the user table until a match is found. On a properly configured system this would be too slow, because you're using a slow algorithm (see footnote).

Also, it would be a massive security information leak if the system told you your password was being used by another.

_{The above example is for illustration purposes only and uses MD5. Never use MD5 to hash passwords - use bcrypt, scrypt or pbkdf2.}

Answer 3

Aren't you basically asking "Is there any reason we don't have public passwords and private usernames?"

They're both just text strings. Your idea of enforcing unique passwords is really just saying that usernames are unique. The label you apply to a text box matters not. We call the string that's private a password and the unique one a username or user ID because it's unique.

Security-wise and looking at it in the normal order of Login/Password: If you required both to be unique then you would open an attack on the database, because every password checked would be checked against every user in the database because you have required your passwords to be unique. So both unique doesn't work. Both non-unique doesn't work because you don't know which account is being accessed. So that leaves just having just one unique string. If you're making a single unique text string, might as well make it a public piece of data and check that first (and we term this data Login/ID/Username).

Answer 4

Let's picture an analogy...

I'm a messenger sent by my king to deliver a message to a certain castle in the Valley of Castles. I know what the castle I want to go to looks like and I was given a passphrase to tell the guard so that I could be let into the castle.

I have two options on how to do this:

1. As you would no doubt expect, the conventional way to do this is to ride to the castle I was sent to and then tell them the passphrase to be let in. This is first using my public information (the castle, visible to anyone who wants to look at it) to log in with my private information (the passphrase).

2. But there is a reverse way to do this. I can get a horn and shout my passphrase across the whole valley for the public to listen to. Since the castle I intend to visit has heard my passphrase (along with all the other castles and the potentially nefarious residents of the valley), the castle I'm visiting should know to expect me.

   I then proceed on horseback to the correct castle and ride across its open drawbridge. But they would let anybody in through this open drawbridge! Now that my private information has been shared with the world, anybody can ride between the castles and enter the one with the open gate.

   If I'm not here to shout this into a horn myself, valley residents could stand at the top of a hill with their own horn, shouting gibberish across the valley until they hear the thud of a drawbridge opening; knowing they guessed a passphrase correctly, they must simply ride between the castles until they find one that's open.

The first option is how it's usually done. There's no reason to change that convention. The alternative is possible, but by sharing your private information first, you make it a lot easier to guess the password of everyone at once before authenticating with public information, i.e. riding to every castle or trying all the public account names. With thousands of castles in this valley or accounts on a website, it's quite likely someone will guess an easy password and then it's a lot easier to simply match it up with one of the few thousand castles or public account names.

Answer 5

Google does not have you enter in your e-mail first for any security reason. It has you enter in your email/username so if you are logging into a work or education domain that wants to have their own landing page for SSO/SAML

Answer 6

If you ask for the password first, you have to maintain the "secret" value in some state while you wait for the username. With a web app, you typically would need to do that storage in some way so a new process could read the value, as the username would come in on a second request. That increases the window of opportunity for the password string to be disclosed, both in terms of time and in terms of ways to get to the data.

By asking for the username first, password verification that uses salted hashing (or not) can already have access to everything necessary to verify the password immediately, and the system only needs to have the password itself available for a minimum of time. It's generally best to have sensitive data available for as little time as possible.

And it's convention. By asking for password first, you'll end up training users to accidentally type their password in username fields elsewhere, probably resulting in disclosure through logs.

Don't do that. :)

Answer 7

To add on; the mechanism of identification vs authentication/verification is decided upon when developing the application. Identification is 1:many, verification/authentication is 1:1

    1:1 - match against one pre-selected result set;

    1:many - match against all results in the DB

Usernames like gmail's are unique. This is not mandatory for all applications, but it sure makes life easier for the verification algorithm as opposed to identification algorithm.

Consider the popular username then password authentication for gmail:

1. enter the username;

   gmail matches the unique username wil all other unique usernames; Yes match, enter password; No match, no access.

2. Enter password.

   gmail just matches the 1 username with the 1 password stored in whatever format; No match, authentication failed. Yes match, get access to your mail.

Pretty straightforward IMHO.

Taking the other side, identification (1:many), the matching process of gmail would be like this:

1. enter password; and as @SilverlightFox clearly indicated, many accounts can have same password.

   matching algorithm matches password to ALL usernames registered in gmail database.
   

   A too conservative result set can be 10 usernames.

2. Enter username;

Whether usernames are unique or can be same, will decide on how much more time the authentication process will run and how many matches are found. If more than 1 match, then we'll have to implemented 3-step login authentication.

Two-step authentication makes life easier for the developer and the algorithm.

Answer 8

In case of google and most of the split authentication setup, the system is basically using the user id to identify the risk associated and determine appropriate login process that it should run for the user.

In case of most of these situation, the user id entered by person is just one input being considered. Along with it a lot of other information (like IP address from where you is accessing, device that user is using - there is a device signature generated and passed along with user id) is passed to a risk determination engine (in most of the banks but may not always be used) which may provide suggested login process. In addition to that system checks the login policy associated with user (i.e. whether it has multi-factor enabled for example). Based on final determination, most of the time you may just get a simple password screen but in some cases you may be asked to go for multiple authentication process (e.g. phone based OTP, etc).