
Ask HN: Why do many sites now put username+password entry on different pages? - jonplackett
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&#x27;s the logic behind it? Is there some security benefit I don&#x27;t understand? Or is it just me who hates this?
======
kayman
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.

~~~
woutr_be
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?

~~~
aliswe
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 ...

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

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

~~~
NicoJuicy
SPA apps wouldn't like that, security wise.

~~~
ta17711771
SPA?

~~~
bruce511
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.

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

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

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

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

~~~
kevsim
How so?

~~~
aliswe
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?

~~~
kevsim
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.

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

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

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

------
dredmorbius
[https://security.stackexchange.com/a/85180](https://security.stackexchange.com/a/85180)

~~~
folmar
TLDR version: no real reason

~~~
perl4ever
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"

