22

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).

Manubhargav
  • 109
  • 1
  • 8
Out of Band
  • 9,150
  • 1
  • 21
  • 30
  • 154
    Forcing unique passwords has a critical security issue: When I would trigger it, I would know that there is at least one account which uses the same password I tried. Account names are usually not considered secret, so I could now try that password with all accounts I know about. – Philipp Sep 09 '15 at 14:22
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/29031/discussion-on-question-by-pascal-schuppli-on-two-step-login-forms-why-is-it-the). – Rory Alsop Sep 11 '15 at 09:27
  • 1
    "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 isn't that hard if you imagine the phising mail was a script that notifys the server about which email recipiant opened the link. Then the chances are high that in case of i.e. google the username just is that email address the person recieved the mail on, what is from that moment on also available information. – Zaibis Sep 11 '15 at 13:24
  • 5
    The other problem with unique passwords is user experience. On a small system with 20 users this might work, but imagine trying to create a unique password for gmail. It's hard enough just to locate a unique username. At that point you might as well auto-assign passwords and just assume it will be on a sticky note within seconds. – Rick Chatham Sep 11 '15 at 18:46
  • 10
    **This is why you shouldn't drink and ask questions online.** – CodeAngry Sep 14 '15 at 12:27

8 Answers8

121

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).

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
82

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.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Wait, what? The salt to use *is* known, it's stored there right beside the password hash... – user541686 Sep 11 '15 at 09:20
  • 10
    Username is used as the key to lookup which hash to use. The OP was asking why a system couldn't ask for password first - the reason is that the system wouldn't know which salt to hash the password entered against without the username to lookup. – SilverlightFox Sep 11 '15 at 09:56
  • No one said the password has to be hashed before the username is obtained though... the question was a front-end question, not a back-end questino. – user541686 Sep 11 '15 at 10:07
  • 3
    "because the salt to use isn't known." -> Just in case this is causing confusion, the problem is that you don't know the right salt for the password you're calculating the hash for. Theoretically you could go through each account and calculate the hash based on the salt and password. However, this would be too slow to be practical if you have more than a couple users. – Matt Zeunert Sep 11 '15 at 10:15
  • @underscore_d: You missed the crucial part of my comment. – user541686 Sep 13 '15 at 19:15
  • @Mehrdad So I did! Sorry. I'll delete my daft comment now. – underscore_d Sep 13 '15 at 19:19
25

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).

Black
  • 379
  • 2
  • 7
  • 5
    @PascalSchuppli He's saying that, even if you didn't have the intention of swapping the meanings of passwords and usernames, there's no way to implement this system in a way where you _don't_ swap their meaning. If the password comes first, it has to be unsalted. If it's unsalted, then it's sitting in a file somewhere in plain text. If it's in plain-text, then you need a piece of information that _isn't_, and your only candidate at this time would be the username. So you would need to salt the username with the password and... – Shaz Sep 10 '15 at 16:56
  • 1
    store the hash of the salted username. _Then_ the system would be secure. But at the same time, you would have completely reversed the definitions of a password and a username. – Shaz Sep 10 '15 at 16:56
  • @PascalSchuppli Your passwords lose entropy because your attacker gains a parallel advantage on the system. If 1 million passwords have been made that's 1 million less you have to check even in the event that you get your system to "work". It's like randomly generating a password but throwing it out if it's not a word. This system is not secure. And as has been stated, if you don't get it to "work" (if there's a method to check more than one user than once such as change password form, sign up) then you get 1 million of these reduced entropy checks each time you send a request. – Black Sep 10 '15 at 21:52
  • 1
    @PascalSchuppli *"usernames are easily guessable even if they're not public knowledge by design"* Obviously, you've never encountered a system that uses the (admittedly terrible) convention: "Your username is h0j7k#X1P%3. Your default password is your last name." They do exist (although I have no idea why). – Dan Henderson Sep 14 '15 at 09:08
12

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.

Keavon
  • 286
  • 1
  • 11
  • 1
    A+ analogy, would read again – underscore_d Sep 13 '15 at 19:22
  • 1
    The order in which information is gathered is irrelevant to whether or not the information can be encrypted. The last sentence of the answer makes up for it, though, as this /might/ allow for easier attacks of the prompt mechanism provides immediate feedback for an invalid password before prompting for the username. But that's sort of a secondary problem. – dannysauer Sep 16 '15 at 03:03
9

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

Doryx
  • 193
  • 5
  • 3
    That's a good point (outlook on the web does the same). There may however be a secondary reason of security/load reduction/limiting the rate at which accounts can be probed. – Chris H Sep 10 '15 at 09:48
  • Maybe that's true of Google, but many systems **do** have you enter your username first for a security reason: [mutual authentication](https://en.wikipedia.org/wiki/Mutual_authentication). – reirab Sep 11 '15 at 20:41
7

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

dannysauer
  • 678
  • 4
  • 9
  • 3
    Plus one for typing passwords in username fields. Big no-no indeed – J Sargent Sep 10 '15 at 16:28
  • 1
    And plus one for mentioning the apparently oft-overlooked fact that taking the (artist formerly known as) 'password' first doesn't require it be fully unsalted, as it could be salted later, but the time delay provides another security hole in this (rather weird, or even just definition-swapping) idea. – underscore_d Sep 13 '15 at 19:26
1

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).

jhash
  • 641
  • 4
  • 7
1

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.

Ombongi Moraa
  • 11
  • 2