5

I am noticing a trend in web development where login screens are no longer showing both the username and the password input fields simultaneously. Instead, you are required to type in your username then click a "next" button which will then reveal the password input field. Why is this?

From my experience, I noticed this started a while ago with Yahoo, at least a couple years ago I think, and Gmail too. And now, Apple has followed suit on most of their websites such as iCloud.com, iTunes Connect, and the Apple ID website. However, unlike Gmail, Apple does not check if you have an account before revealing the password field. It literally just unhides the password field.

It appears to be for security purposes, but I am not seeing how. It is interesting that some web developers were attempting to steal credentials recently. On page load Apple's password management solution would autofill credentials, possibly revealing credentials to nefarious websites (or even if not nefarious it still provided user information without explicit consent). This was just recently addressed by no longer autofilling on page load, instead the user must invoke the autofill after clicking into the field. I believe not long after that was addressed, that's when Apple updated their login screens to hide the password input field, which may not be a coincidence. Notably, their implementation breaks autofill of both username and password - on their sites you now have to select the username field, invoke autofill, click the next button, select the password field, invoke autofill, and click the next button to log in - it does not fill in the username and password field upon the first invocation because the password field is not shown until after the username is filled and committed.

Does hiding the password field until the username is committed increase security, and if so, how?

Jordan H
  • 153
  • 5

1 Answers1

5

UX Design

First of all it's a good UX design. It decouple Identity (your username) from your Authentication Method (Something you Are, Something You Have, Something you Know) and in the age of different authentications sources (Google, Facebook, OpenID, Internal) it's a sexy way to make them look as one.

Security

Brute Forcing

You increase the number call you need to make to a service, thus increase the time it takes to get a password.

Multi-Auth Sources

As mentioned in the UX portion, we decouple Identity and Auth. This makes it easier to develop 2FA applications which can use multiple patterns.

Separate Identity Source

Maintain a public identity source separate from your authentication. Think about having a Identity Management Server which holds all the information about you, that can be used across your entire business and than allowing different types of people authenticate in different ways.

I'm sure there are more if I sit and think about it.

Shane Andrie
  • 3,810
  • 1
  • 13
  • 16
  • And then there's Microsoft; the same login form can be used for multiple account types, even sharing the same username. `login.microsoftonline.com`: if you register personal Office 365 account with work email as username and also your company moves to Office 365, you'll end up choosing the correct account every time after typing the username and before you get to the password field. I don't think this exactly falls to the _good UX design_ category mentioned here. – Esa Jokinen Apr 19 '18 at 16:15
  • 1
    I certainly would not classify it as a good UX design, as it’s now an 8 step process to log in (on an iPhone X using auto fill) when it used to be 1. Quite conversely, I’d classify it as a truly awful user experience. – Jordan H Apr 20 '18 at 13:12
  • @Joey I guess I'm not sure what you mean. Web Apps are phone agnostic, (or should be). – Shane Andrie Apr 24 '18 at 15:46
  • Yes but the design heavily affects the user experience and it likely is different on different devices. For example on iPhone X when the username and password field are visible, to log in you tap the username field, invoke autofill, authenticate with Face ID, and tap the continue button. That's quick, easy, and a good user experience. But when the password field is hidden it's a horrible UX because it's suddenly an 8 step process: tap the username field, invoke autofill, authenticate with Face ID, tap continue, tap the password field, invoke autofill, authenticate with Face ID, tap continue. – Jordan H Apr 24 '18 at 16:04
  • 1
    I can see why it could be a better UX if you do support logging in differently based on what username is provided, as opposed to redirecting and logging in again on another web page for example. In the case of Apple, they don't log in any differently based on the provided Apple ID, so hiding the password field was a rather odd thing to do I I thought, especially as it "breaks" autofill, making the login experience much more painful. But I was interested in the security implications of leaving the password field visible, or what benefits are gained by hiding it. – Jordan H Apr 24 '18 at 16:11
  • It turns out Apple does delegate authentication to another identity provider (like Microsoft Azure), and the user enters their password on their site. So in that case I can see why hiding the password field made sense. – Jordan H Jan 30 '20 at 00:55
  • It is NOT a good UX design. Source: I am a user and it is definitively an experience that I hate. You're decoupling things that belong together. Stop doing it. – tandrewnichols Apr 28 '21 at 01:54