60

Well, I only have two examples, but it seems to be a slowly growing thing.

First, I noticed that hotmail.com/live.com started to do this - ask for the email address on the first screen, and then you have to click 'next' and then enter your password.

... Man, is this annoying! At least trusty gmail knows good UX. A few months later gmail are doing the same thing.

So, I assume there is a security reason for this workflow because it can't be for UX (?)

But what is the reason? Is it to do with tricking bots/making their life more difficult?

Dan.
  • 581
  • 1
  • 4
  • 6
  • 7
    This has been discussed on UX.SE: https://ux.stackexchange.com/q/56260 – Arminius May 29 '17 at 13:06
  • @Arminius Thanks, but it seems to be mainly a UX discussion. The guy with the top answer does talk about security, and if anything I think he's against this workflow. After reading his answer, I actually have a good reason why this 'two step' approach if bad (allows someone to figure out if you are registered with the service) – Dan. May 29 '17 at 13:32
  • 2
    what @Arminius wants is to weave a web between related answers, **dear Dan.**. It is no problem addressing a problem from another prism in here. It is not a duplicate warning. It does not subtract value from your question. But you should tune down the subjectivity in your question. – Mindwin May 29 '17 at 15:18
  • @Mindwin no feather-ruffling intended honestly, was just explaining what I took from the linked question/answers – Dan. May 29 '17 at 16:20
  • First paragraph: not constructive, can be removed without loss of meaning. - - - - Third paragraph: The biggest offender. Ditch it. - - - Fourth paragraph: cite the linked question in ux.se. From the amount of upvotes, it can be considered **isn't for UX** instead of **can't** – Mindwin May 29 '17 at 16:48
  • 1
    @Mindwin Feel free to edit it. I'm pretty confident in my assumptive sentence about "can't", though. In what world be it be good UX to make the user have to click once more than otherwise (to security) necessary. – Dan. May 29 '17 at 17:07
  • @Mindwin You can easily propose an edit to improve the question. :) I think it was perfectly fine to point out the related UX thread and by Dan to comment how it does or does not help with answering his own question. – Arminius May 29 '17 at 18:06
  • 1
    Something to consider: I have a work email address that works as a log in for Microsoft. The login page asks for a login and password, but it redirects me as soon as I type the login, because no password is actually necessary (it uses the Windows account or something). In that case, it would be better for meet personally if the password portion was on a different page, and was only shown to people it applied to. – Kat May 30 '17 at 01:58
  • @Kat You're lucky - my system is restricted for various reasons and the system account login doesn't work, so as soon as I move out of the login field, it redirects to the corporate login screen, where I do have to enter the password. If I'm unlucky and had kept the MS login screen open too long, I get redirected back to it. :/ Worse, Chrome refuses to remember my corp ID for the Outlook login screen, so I have to type it *every single time*. – muru May 30 '17 at 02:56
  • 1
    @muru don't misunderstand me, I still have to go through several screens to log in, which doesn't work half the time, and is overall quite obnoxious. :) I think your case of being directed away from a screen with a password to another screen with a password warrants a change even more so than mine does, though. – Kat May 30 '17 at 03:04
  • Was just wondering this this morning. It's really annoying. – Lightness Races in Orbit May 30 '17 at 16:13

6 Answers6

34

Security / Privacy disadvantage

There are security and privacy risks involved with this approach when badly implemented. An attacker could figure out if the email- or login already exists, when not having a default flow. As mentioned @Mario Trucco this can also be done via the registration process.

  1. Security is at risk: Because it becomes easier for an attacker to bruteforce their way into a system. It will make guessing easier if you only need to guess a password, instead of both the username and password.
  2. The privacy of users is under scrutiny. (Other people will know if you are listed at that website.)

Reasons why this is implemented

I found this on the Google documentation:

This new Google account sign-in flow will provide the following advantages:

  1. Preparation for future authentication solutions that complement passwords
  2. A better experience for SAML SSO users, such as university students or corporate users that sign in with a different identity provider than Google

Security Advantage

  1. It may enable more personalized customization options for security such as phrases or images providing more security options (see example below). This would reduce the scope of phishing as the screen generated would be specific to the user and would vary from user to user.
  2. Because users can have different ways of authenticating and the identity of the user is equal to the username this will make it easier server-side to redirect traffic to the users form of authenticating

Example image Example Image -v The users sees 'his/her' personal Image or Sound. If that image does not correspond with the image given at registration. The users knows this is a fake login.

Community
  • 1
Ludisposed
  • 848
  • 1
  • 8
  • 21
  • 4
    Hi thanks for your answer, but it seems you are providing reasons for NOT using the process described in my question, I.E I agree with you and I don't know the reasons TO use this process, as used by hotmail and gmail. – Dan. May 29 '17 at 13:55
  • Edit, will hopefully explain the advantage of using this kind of format – Ludisposed May 29 '17 at 14:14
  • 3
    I like that personalised login screen anti-phishing solution, clever. Though tbh I don't think I would notice the lack of personalised image if the bad guy also removed the 'Tip: If this is not your....'. But provides a good answer anyway. I may implement that into my own projects. Thanks for your answer. – Dan. May 29 '17 at 14:24
  • 2
    In some cases at least the application doesn't actually require a valid username to progress to the password stage, they will silently accept an invalid username and then just drop the request after the password is entered – Rory McCune May 29 '17 at 14:56
  • @Rory This is true. But a bad implemented 2 step login, with a postback of something like: Your username is not valid. poses a security risk. But with a good implemented solution this is not always the case. – Ludisposed May 29 '17 at 14:59
  • 15
    An attacker can already find out whether an username/email exists trying the registration process – Mario Trucco May 29 '17 at 15:14
  • 2
    You should add a text caption explaining what is in the image, because people that cannot see images (imgur blocked, screen readers, text browsers, etc) get no value from your image. – Mindwin May 29 '17 at 15:16
  • @Mario Trucco This can also be done via the registration process, but this is more difficult. Because it requires more fields and/or uses captcha. – Ludisposed May 29 '17 at 15:24
  • @Mindwin add verbose description of image, only have phone atm, so may update answer if necessary – Ludisposed May 29 '17 at 15:25
  • 3
    What prevents the phishing site from displaying the personalized image? – xehpuk May 29 '17 at 16:52
  • @xehpuk Yeah I guess it wouldn't be any good if the attacker was targeting you specifically and he knew your email address, but this would stop those mass-phishing attacks - The hacker would have to personally enter every email address to see the image for that email address, vastly reducing his chances of a successful attack due to it being a numbers game. He would know this and probably not bother trying it in the first place, unless he is just trying to target a small group of specific people. – Dan. May 29 '17 at 17:39
  • 7
    @Dan. No, you as the victim would enter your username on the phishing site which then could fetch the image from the real server and display it to you. – xehpuk May 29 '17 at 17:43
  • @xehpuk If the phishing site is loading the real site in an iframe, then I think there's no chance of that happening as you would be sent to the real site the moment you submit the first form. If the fake site's plan is to actually mimic the real site (by recreating it from scratch) and then manually submitting your data to the real site and back, in this case I think there are simple/achievable precautions the real site would put in place (e.g. not letting anyone scrape the image) EDIT - sorry ignore that - you can submit the iframe-ed form without redirecting the user from your domain – Dan. May 29 '17 at 17:48
  • Perhaps to also prevent triggering autofill. Although many browsers are smart enough to see through this. – 1234567 May 29 '17 at 17:48
  • Few years ago I implemented that way for a community site. The reason was pretty much what is explained here. When using different authentication methods (like OAuth), it makes no sense to present a password field right away. I was able to simplify the registration and "lost password" in a single place, which I think it was neat (allowed me to strength a single entry point). As Mario Trucco said, there are other ways to figure the login name, so it really doesn't pose a higher security risk. It actually helps user to know what is wrong and to minimize the failure count before being blocked. – lepe May 30 '17 at 06:56
  • 1
    @Ludisposed uses captcha? Not on google it doesn't. You just need to type the email it will tell you if it is already in use or not before you need to submit. – wannabeLearner May 30 '17 at 12:06
17

Passwords are not a requirement for authentication in some cases.

The username generally determines how and what authenticates a user; in a federated login the username will identify the Identity Provider that will authenticate the user. That ID provider might use a password but is not required to; many alternate login flows can happen passively or use other information (e.g. smart card or other hardware token, biometrics, etc.)

Capturing a password in these scenarios either leads to the user entering the (sensitive) data twice (since Hotmail/Google don't need that info, the ID provider would have to request it a 2nd time) or entering data that is not needed at all.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Joe
  • 426
  • 3
  • 10
5

The other answers have hinted at this but not really, I think, clarified the potential security benefits of a two-step login like this.

Doing things this way allow you to separate out the identification and authentication stages of the login process. Say for example you have an application which has multiple levels of user account with different authentication requirements (e.g. some users have 2FA some just have password auth.) or perhaps something like a portal system with different backend user databases.

By taking the username on screen one, you can then present the correct authentication type for that user on screen two. As mentioned by @ludisposed there is a requirement to have a "default" flow for users who don't exist to avoid revealing valid/invalid usernames to someone who trys to guess valid accounts on the system.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
4

The primary reason for separating the username/email entry from the password is Federated Authentication. In many modern web applications, the user signon is handled by the user's own organization (your company or school for example). The website you are visiting (known as the Service Provider) will keep a list of the organizations that they have established federated authentication with, and the domain(s) used by those organizations. Once you have provided your email address, the service provider will use the domain name to determine the organization, and send you to that organization's signon system (known as an Identity Provider). You complete the signon at your organization, and then your organization sends you back to the original website, with your identity information in the form of a web cookie most commonly. For more information, I would recommend you research SAML and OpenID Connect, which are the two protocols most commonly used for this.

Byron Jones
  • 265
  • 1
  • 4
  • this is covered by other answers – schroeder May 30 '17 at 16:18
  • 1
    Which answer are you referring to? The other answers only seem to discuss federated authentication tangentially, when this is the _primary_ reason for the UI design he is questioning. – Byron Jones May 30 '17 at 17:27
1

Conditionally offering different ways to authenticate

Submitting your username/email address alone allows them to look up your account and check what authentication options they should offer you, based on how your account with them is set up.

For example: whether they should just ask for for a password, or send a single-use code via SMS, or redirect your web browser to a third-party service's authentication page.

Michael
  • 111
  • 2
-5

Its another way to ensure you are committed to visiting the website and signing in. Also its another way to ensure you are not a robot or script. Its also a way to monitor you interaction with the login. It all link to privacy and security

Chukwu Remijius
  • 101
  • 1
  • 7
    This login process does nothing to ensure you are not a robot or script. Your last line makes no sense in relation to the rest of your answer (you seem to contradict yourself). – schroeder May 29 '17 at 21:07