I see this more and more lately: go to log in to some site, and they only show the username field. Enter username, click Submit, then a password field appears. Enter password, click Submit again, and then we’re logged in.
This makes using a password manager super annoying, because I have to trigger the autofill twice.
Is there some security-related reason more sites are doing this? Is it an anti-bot thing? I’m just really curious, because it seems so pointless on its face, but it seems to be spreading.
SSO has already been mentioned, but expanding on that for those that aren’t familiar:
When you have a big organization with lots of people that needs to access maybe dozens of sites to do their work, it quickly becomes a nightmare to manage. You’d have to invite the user on dozens of sites, you can’t easily control their access, it’s easy to forget about some accesses. You have to care about users using a good enough password, make sure to sign up with their work email, etc.
Enter SSO. The company maintains a central directory for their users, where they can enforce password policies, enforce the use of 2FA authentication, and can out users into groups which grants them access and permissions to external services. So they can make say, a “developers” group and it gives you access to a testing AWS environment, read only access to logs in DataDog, access to some settings in Cloudflare, etc. They put your user into that group and you automatically get access to all that.
Of course at that point, you don’t have a password for any of those sites. But you need a way to log in. So that’s why the login process is multistep: you first enter your email and submit that. From there, the site can determine if you belong to an SSO organization and redirect you to the SSO flow where you’ll authorize the log in and your company can also grant or deny the access to that site through your company email account. And then you’re in, no password required because supposedly you’re already logged in to your company email or logged in as a side effect of logging in to a company computer.
If you have a regular account, then the site can prompt you for your password, and optionally your 2FA code. They could just put all 3 fields on the same page, but at that point you don’t know if the user needs a password, or if they need an MFA code as well.
Plus, if you don’t have an account at all, it can then show you a registration page to enter the rest of your details, so you don’t even need a separate registration flow either.
To add to this… Sites that initially show both the username and password fields can get very confusing when using SSO. Dropbox used to be like this - It’d show both fields, but as soon as you entered an email address that uses SSO, it’d hide the password field. Sometimes the request would fail and so it’d still show the password field, but no passwords are valid for an SSO account, so it’d just look broken.
Once I learned how this was implemented I now only enter a@company.com into the email since it’s going to redirect to a company sso anyway.
As the other person said, this is a classic SSO pattern. Your email or sometimes just organization ID that you enter in that field will send you off somewhere else to sign in, then you don’t get the password field at all.
On applications I’ve worked on, pretty much every time we’ve integrated SSO using oauth we’ve modified the entire login form to look the same. That means enter email, and we either send you to your provider login page or we show a password prompt after. Not a good reason in my opinion, but one that shows a similar UI regardless of login type.
Ah yeah, this makes sense.
I have seen other services include an explicit SSO link under the user/pass form, which IMO is clearer what’s actually going on, but I’m sure that structure hopelessly confuses lots of less technical users, too.
Paginated login
Microsoft enabled it in ADFS on WS 2019. I know there are plenty other places it’s used, but It’s the example I’m most familiar with.
There can be a security element to it depending on how the server handles paginated auth as it separates the password field away from the user ID. You can also interject the second factor first before the password to protect brute forcing.
But the larger reason I’ve read is that it’s easier for end users to use. Here’s MS talking about it with ADFS.
“Instead of a long form to fill out, a new flow takes you through the sign-in experience step-by-step. Our research shows that with this approach, our customers have more successful sign-ins.”
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-paginated-sign-in
Whether this is true or not is debatable. I’d love to see passwords die out. I doubt I’ll see that in my lifetime though.
I’d love to see passwords die out.
Me too, public key based authentication would be so much better, and safer too. But that would require intelligent end users, which is impossible.
How would you replace it instead? Biometric?
How would you replace it instead? Biometric?
Biometric or certificate on a physical device (e.g. Yubikey) auth via Webauthn/FIDO2 is becoming more popular.
Interesting finding from Microsoft that it leads to fewer user errors, thanks for sharing!
You’d love to see passwords die out? How would you protect personal data?
There’s a million ways to authenticate a user. Passwords are just the simplest to code (poorly, haha) and deal with. You don’t even have to store the password (just a hash of it) which means you don’t need to encrypt your database to keep them secure which also means you don’t have to deal with decryption keys, key rotation, etc.
With passwords you also don’t need to deal with 3rd party hardware or systems. You can handle it all right there in your code using methods that are so common and popular you can copy and paste them right out of StackOverflow (haha).
Now as to, “how would you protect personal data?” That has nothing at all to do with passwords! Protecting personal data is an orthogonal concept to authentication.
Protecting data–any data–is a very holistic thing: You have to do a threat assessment and figure out where your boundaries are and take measures to protect literally everything in order to prevent attackers from being able to get to it. Example: Attackers could get access to “personal data” by waltzing out of a data center with the correct server/hard drives in their arms. Passwords be damned!
Biometric (fingerprint, etc) or private keys via physical devices like Yubikeys.
This makes using a password manager super annoying, because I have to trigger the autofill twice.
Some - if not most - password managers let you configure the auto-type-sequence for each password individually (e.g. KeePassXC). Just change the default
{USERNAME}{TAB}{PASSWORD}{ENTER}to{USERNAME}{ENTER}{DELAY X}{PASSWORD}{ENTER}with X being a delay in milliseconds that pauses the sequence until the new page has loaded completely.I don’t have an answer for your original question, but I have noticed some forms still auto fill the password field. Guessing it’s handled by hiding and un-hiding via css, so the extension can still find it and auto fill
I think PayPal may be one off the top of my head if I’m not mistaken
Yeah, I see this one happen occasionally, and it makes me marginally less grouchy.
If the transition was anything but fake (i.e. they do something with the user name before showing the passwordfield) I feel like that would be a bigger security hole. A leak of some sort of info about the username maybe.
They usually just check if it needs to go to an SSO sign in. The only thing that will happen is if the email or org id you entered belongs to an SSO identity then you’ll be taken somewhere else to login. Otherwise, whether the username/email exists or not, it’s the same password flow.
It’s done this way for SSO. Sometimes instead of providing the password you will be redirected to your company’s SSO based on the email address domain.
As others have said, likely SSO related. We do this with our sites at the company I work for. Some sites are internal, some are client-facing. But you can be logged into all at the same time through one SSO portal. If you’re an internal user, you’re redirected over to the internal SSO after entering your email, whereas external users get a generic password screen.
