Ask HN: Why do many sites now put username+password entry on different pages? | Hacker News Reader

Ask HN: Why do many sites now put username+password entry on different pages?

45 pointsjonplackett32 comments

I just find it irritating when typing it in, AND it messes with password managers. But it seems to be happening more and more. What's the logic behind it? Is there some security benefit I don't understand? Or is it just me who hates this?

View on HN

The reason your username and password are on different pages is to handle federated identities. Take a typical saas product. Initially you build your own login username and password. As you grow your users ask to login using gmail, LinkedIn or Microsoft so they don’t have to remember multiple usernames and passwords. If you enable third party login it means you have to redirect the site to the third party login page to authenticate.

To accomodate that you design your page so the user first enters username. In your system you check based on email who the identity provider is and redirect to that login journey.

For e.g. if Microsoft you redirect to Microsoft login page to authenticate.

If successful the third party login provider will send you back to your app with a JWT. In your app you check if the JWT is valid - if so allow access.

On first entering email on login, If your login provider is your own app, you redirect to your own login password page.

JWT == JSON Web Token

I had to look it up.

https://en.m.wikipedia.org/wiki/JSON_Web_Token

That seems like a strange flow, it means the user first has to input his email on your app, then you redirect to Microsoft, user will have to input his Microsoft email and password, and redirect back to your app.

This means the user now has to remember which email he used on your app, which is not very different from remembering which third party provider you used before.

Maybe I'm missing something, but how would you explain why Google does this two step login process?

You often don't have to put in the email again, thanks to eg. the username hint.

And then, if you're already logged in according to the auth provider, you don't have to type your password either.

A good thing about tgis is that the providers can require different kinds of MFA at their discretion though.

But, what would happen to that poor app if I have a live account associated with my gmail and a google account associated with my o365 mail? ....

Come to think of it, I have an email account to which I have associated an ms live account AND an o365 corporate account, and a google account ... Very confusing ...

Typically you don't even ask a user for an e-mail for an OAuth based login. I think you're talking about OpenID Connect, where you indeed need the e-mail to know which login provider is used. I haven't seen that in the wild for a long time though, most sites that offer "Login via X" use an OAuth 2.0 based login flow, either with server-side tokens (e.g. Github) or JWT token (e.g. Google).

Nitpick, OIDC is built on OAuth

THere are many websites without the option of federated identities - the 2 main supermarkets here in the UK do it for example (tesco.com, sainsburys.co.uk).

Maybe they're just joining a trend that they don't realise has benefits to others but not themselves?

SAML, single sign on, 2FA confirmation, etc.

For example, I don't know what login method a user would be using (our own password? or redirect them to their corporate's auth portal) until they enter their email.

Single sign on is indeed the reason. However, I don’t agree that this behavior is a good thing - as an industry we’ve failed; we’re inconveniencing a large chunk of users because of an implementation detail. SSO should’ve either been implemented transparently in the underlying protocols or the browser (like Kerberos actually is) or at the very least provide separate login pages so that regular users can bookmark the right one and avoid wasting time if they are not using SSO.

they could just hide/show the passw field and not put it on a diferent page. make the email request on background

SPA apps wouldn't like that, security wise.

SPA?

Single page application.

Basically a single page request (that then immediately fetches all the associated JaveScript and CSS) to run the entire app.

It is popular now because its a very small step from that to having a PWA (progressive Web application) which is progressive in the sense that it can be completely cached on the users device, and work with no connection to the Internet.

It also improves page-load performance in connected situations by there being no pages to load (after the first one).

While a solid approach, SPAs can suffer from long initial load times, as well as a tendancy to suffer from complexity that comes with any monolithic large app.

Bad UX imo. User types email and then the password field disappeared! How am I gonna log in now?

Interesting - yes that does happen with google and that seems like why

But it also happens plenty of places where single sign in isn't an option. Like the biggest two supermarkets Tesco.com and Sainsburys.co.uk here in the UK.

Guest accounts

Then we all have to enter our email twice. Why not just ask for the info you actually want: login with password or login with sso buttons

Because you could have thousands.

You'd have to iterate through every customer with SAML / OIDC set up.

Even if you are just using end user, it's sometimes confusing if there are 10+ options because you have to remember... Ok not only do I gotta remember my email I used, how did I originally sign up? .. was it with Google? With Facebook... No wait did I use email and password...

I'd like to mention that bitwarden seems to handle that rather well (the browser extension at) on the sites I tried. (Backblaze and google login for example)

1Password also deals with it well. For example on Google, Microsoft, and Atlassian.

I have also not had issues using KeePassXC with the KeePassXC-Browser plugin for Firefox.

If it's done properly, it shouldn't mess with password managers. The trick to doing it properly is to put a hidden password field on the first screen so the password manager can still fill it in. If the page sees them both filled in, it knows it's not dealing with a federated identity situation and can just log the user in.

Other services show both the username/password but send requests to the server as the user types their email address and take away the password field if it's an email associated with an SSO domain. I believe this is how Dropbox does it (could be remembering wrong).

Done properly, are you sure about that? Sounds like a security risk to me...

How so?

If I put it this way ... Don't you think that a password manager entering your password into a hidden input sounds a little strange?

Not at all. You're explicitly performing an action with your password manager on a domain you've already decided to trust.

Go head and inspect the source for the Google account screen where you put in your email and you'll see a password field a few elements down with the name "hiddenPassword" with "display: none" set on it. This is a well known approach.

I don't do this myself, but I did consider doing it, because to some degree it simplifies work flow in the login process.

By way of background I should point out that logins can be a Lot more complicated than just "enter login and password" and critically the complexity may be different per user.

For example some users have 2FA turned on, so we need to collect user name, password And say SMS code. This is the very tip of the iceberg.

So identifying the user first can make it easier to then determine which path to follow.

Ultimately I didn't go this route because AJAX can be used to get the user-name when entered. However it can then get complicated when the user name and password are entered and the login button clicked at the same time (like by a password manager).

So multi-step input is easier to code.

I thought the original intent was to help prevent phishing. If you have to enter you username on the initial page, the subsequent page could then present you with your profile picture and name. That would then condition the user to look for it. I have no evidence to validate that, but just how I thought it was designed to work.

All of the other comments seem to have much more logical explanations, like SSO and OAuth options.

evernote.com shows the username field, and you have to click "continue" and it has some dumb slow animation that reveals the password field. If you get your password wrong, the screen freezes for a few seconds, then the password field disappears and the reveal animation happens again, now with the "Incorrect password" message.

Maybe they really want people to use their app.

https://security.stackexchange.com/a/85180

TLDR version: no real reason

Hidden in the comments:

"A big reason why this is done is to prevent passwords from accidentally landing in the username field, which is logged, & is correlated in all sort of reports"

Reply on news.ycombinator.com