
Why are the username and password on two different pages? - jeremiahlee
https://www.twilio.com/blog/why-username-and-password-on-two-different-pages
======
jsf01
This just prevents me from being able to quickly hit tab to get to the
password field. It also makes it so that my password manager can’t auto fill
everything in one go.

~~~
AsusFan
Define "one go".

Keepassxc auto-type allows you to add a delay between writing the username and
writing the password.

Works just fine for me in these "two step" login scenarios.

Edit to clarify:

This is what I am talking about:

[https://github.com/keepassxreboot/keepassxc/wiki/Autotype-
Cu...](https://github.com/keepassxreboot/keepassxc/wiki/Autotype-Custom-
Sequence#delay-n)

~~~
jsf01
That’s added friction. Every standard username/password form takes me only one
click to enter into my password manager. Your timing based approach also adds
uncertainty. What if the second form is different now? What if the first
request doesn’t finish in the specified delay time? When dealing with
credentials, I don’t want to think about any of those things.

~~~
greggyb
What if the one-page login has a change that requires two tabs to get to the
password field, instead of one? This has happened to me on multiple sites.

What if the one-page login is changed to require additional information? At
least one airline loyalty program I belong to now requires User Id, Last Name,
and Password to be filled in.

Credential-collecting workflows have myriad ways to break the "standard" of
_USERNAME <tab>PASSWORD<return>_ that are present regardless of how many pages
the workflow spans.

~~~
koolba
> At least one airline loyalty program I belong to now requires User Id, Last
> Name, and Password to be filled in.

Ha! Yes AA’s login field requiring both your name and id is annoying but
United takes the cake for asking you “secret questions” on every login and you
have to pick the answers from a 10-choice drop down.

~~~
greggyb
I didn't remember that it was AA. And ultimately, that's my point in all
responses to this article.

I don't know the login process for specific services I use. I don't know what
they require or how many pages they are. It takes me less than a minute to
configure a login sequence. And it works.

So, to me, none of these login workflows are broken. And the games of "yes,
but" that others (not you) are playing is silly, because people are trying to
tell me I'll be frustrated doing a thing that has decreased frustration for me
for years.

------
CaliforniaKarl
I completely support the two-page mechanism, for several reasons.

I very much dislike the model where, after entering an email address, the page
contents change to redirect you to a different login. For one thing, that’s a
separate call out to the server, which takes longer than you expect on slow or
lossy networks.

Also, I wonder how that UI change appears to someone using a screen reader. I
think that, given a choice between this method and a two pages, the two pages
is friendlier to the visually-impaired. But I would love corrections on that!

Having an API to match username to login method also means you have more code
to maintain, and you have a potential source of information leakage to
protect. With separate pages, you can use more-generic technologies, which
react upon seeing a weird access pattern (like CloudFlare’s DDoS protection
interstitial).

I dislike the optional password method for two reasons. First, infrequent
users may not remember that they use SSO. They enter a password. If the site
takes them to SSO, then it just reinforces the wrong notion that a password
_is_ required.

It can also make things confusing if a person uses a site twice, once for work
(which uses SSO) and once for home (which uses a password). In this situation,
having a username and optional password on one page may interact weirdly with
a password manager.

Those were just the first things I thought of. I expect there are more, but
then I’d start rambling!

~~~
hrktb
The part I dislike about the two page logins is they often don’t repeat the
login name on the second page.

For Google’s logins for instance, there are times when my password manager
doesn’t get what user I am supposed to log as, and I might also not remember
what I chose on the first page (just showing me the account’s name doesn’t
help when I use several accounts with all my real name)

And the opposite issue with realizing on the second page that I am not on the
right user or want to change. Depending on the context (e.g. a browser pane
popped up by an app) going back is cryptic or just not well supported.

In that sense it’s less confusing in some way, more in others. I don’t see it
as a very good alternative or something that should win the world.

------
echelon
I hope someone from Twilio engineering or product management reads the
complaints here and actually redesigns their login flow. Multi-step login
flows are trash.

~~~
kosievdmerwe
Especially on iOs, where I have a password manager that won't fill in the
email/username step, so I have to manually either find that or type it.

If it's one screen I can just prefill both at once.

~~~
ceejayoz
PayPal handles this pretty nicely, in a way that iOS seems to be happy with.

They have both fields in the HTML, but the password is hidden until the email
is submitted. My 1Password iOS integration handles that fine - when I go to
the second step, password is there.

~~~
mikewhy
Initially I was worried about this two-step process in relation to password
managers, but I can’t think of any examples that trip 1Password up.

------
yellowapple
I love how this article cites Brad Frost's "Don't Get Clever with Login
Forms"[1], yet at the same time advocates specifically for doing one of the
"don'ts" listed in that cited article ("don't split login across multiple
pages").

Reading through Twilio's article, I still don't see a satisfactory explanation
why they did it this way instead of just presenting both fields plus a list of
buttons for other authentication methods (like what they even acknowledged to
be the norm, citing examples like Pinterest and Twitch). If you're trying to
dynamically choose the authentication method by looking up some preference
associated with the user's email address, then you are exhibiting the textbook
definition of overthinking the problem.

If users want to login with Google/Facebook/Twitter/Microsoft/etc.
credentials, provide a button for it and call it a day. Those login methods
will automatically (in all likelihood) provide an email address for your app
to tie to its internal "user" representation (though you might have to
explicitly request that particular permission in the OAuth or SAML or whatever
flow).

[1]: [http://bradfrost.com/blog/post/dont-get-clever-with-login-
fo...](http://bradfrost.com/blog/post/dont-get-clever-with-login-forms/)

------
timw4mail
...because apparently implementation details have trumped usability.

Regardless of if you use a password manager, or enter the credentials
manually, it's adding another step in the flow of an already irritating
system.

~~~
hn_throwaway_99
I don't understand this. It's not an "implementation detail", it's a business
requirement. That is, the business requirement is that some email addresses
have different authentication requirements (i.e. with password or without).
There are certainly different ways to handle this, as the article goes over in
detail, but they all have different usability tradeoffs, and frankly I think
the multi-step is less confusing than some of the other options.

It frustrates me when people, especially engineers, gloss over trade-offs that
had to be made because their _particular_ use case isn't as well supported
without considering how all users are affected.

~~~
Mirioron
Choose your authentication method before entering the login details then. What
are they going to do if they need to add support for electronic id cards? Add
a 3rd page into the login step?

~~~
hn_throwaway_99
So instead of letting the system, which can easily determine which auth system
to use based on the email, you're putting the responsibility on the user to
remember what they used when they have potentially tens/hundreds of web
accounts? Yet somehow putting the password on the next page is worse??

~~~
Mirioron
If they're going to use a password manager then the password manager will tell
them. Your system can't determine if the user signed up with Google or is
using an electronic id card either.

~~~
hirsin
Yes, it can. How do you think Auth works? You know what auth methods the user
has. Otherwise you can't really validate their auth.

~~~
Mirioron
If you're using an electronic id card then you don't have the same username
and password values that your website uses. You likely won't even use the same
fields. Authenticating through that usually just involves a separate button.

~~~
hirsin
Auth systems don't key off of usernames... When we added FIDO support there's
still a backing user store that records user x has FIDO y, with a recording of
the public key. That's how the pairing works. You can see it today on
login.live.com

------
_salmon
If you're going to have a 2-page login worflow, just make sure that you aren't
making network calls client-side to check if the email is registered on the
site.

This is a super easy way for attackers to enumerate valid email addresses to
then come back and stuff credentials.

------
tracker1
Currently working on an authentication server that will have local users, and
integrate SSO and 2FA options...

The break in flow is kind of required... I _COULD_ display a disabled password
field for the purpose of showing it... I instead opted for having a hidden
password field (by size/opacity) so that password managers and auto-fill can
populate it... when the user clicks next, the password field will be filled
and continue. I _could_ just try logging in with the entered password, if
populated then display the password field without error, but this would/should
probably count against the bad password attempts.

There's no perfect way here... dealing with the blur event for the text field
for similar behavior will also cause alien events and mess with accessibility.
Having a clear "Next" is at least a consistent in terms of a11y.

------
Bootwizard
I designed and implemented a new login flow for the app I work on. We went
from the username and password on separate pages to all fields on a single
page and increased our retention significantly within the login/sign-up flow.
Turns out the more steps you add to your sign-ups process, the less people
want to sign-up at all.

We measured a 20% loss in users per click for the previous sign-up flow. That
was quite a shock to see.

------
intellix
Google login does this but a password manager autocomplete seems to complete
the whole process in a single stage. Dunno if it's cause of a hidden password
field or something

------
greggyb
I see multiple complaints about breaking password manager workflows, but
Keepass has allowed me for years to use any simulated input sequence for
credentials.

I have many passwords configured with:

    
    
        1. Type username
        2. Type <ret>
        3. Pause 750ms
        4. Type password
        5. Type <ret>
    

Some need an extra tab in there to give the password field focus for input. I
have a short template for this, so I can just copy-paste the input sequence
into any new password.

~~~
robk
Except an error will lead to your password being typed in plaintext
potentially if the timeout expires and the focus goes back to the login field
or another field or url bar

~~~
greggyb
What is the threat model here? How am I compromised if part of my password
gets typed somewhere else?

It's already plaintext when it's typed. If there's a keylogger on my machine,
they're getting the password.

If it's typed into another field, I'm really not concerned. I'm not logged in
yet. So if it gets typed somewhere and submitted through a form, it may end up
in a log somewhere un-associated with my username.

If the concern is that it's seen in public, this is valid, I guess, but not a
concern for me. I access private services in private. Probably 90% of my
computing is done in my home.

~~~
panic
Your browser could crash during step 3, moving focus to the next open window.
This window could be a chat window. It's an unlikely situation, but it's not
inconceivable.

~~~
greggyb
This is not a concern in my threat model.

------
cabaalis
I'd like to know HN opinion on using the first form to pull in and display a
pre-selected identification image or statement. Basically to show the user
something associated with their account that a phishing site would not have
access to, before they've typed in their password. I've seen banks do this and
am starting to see it in healthcare.

~~~
kstrauser
They're awful. If you go to a phishing site and _don 't_ see the image, and
you're in the 99% of users, you're not going to say, "oh no, this must be a
phishing site!" If you notice at all, you're going to think "they finally got
ride of that stupid penguin picture".

Did you ride the bus today? Did you notice whether they removed one of the ads
you saw yesterday? Yeah, neither did I.

~~~
chrismorgan
Exactly. This is why EV certificates are a waste of time, too. People notice
the _presence_ of things, but they don’t notice their _absence_.

------
afandian
On mobile GMail sign-in (Firefox on Android), there's a form with an email
address and a 'Next' button.

Type into the form and press return and... it clicks the 'forgotten password'
link. I'd love to know the UX behind such a significant change to normal
behaviour.

------
solatic
Why do you need to have a single login page? Why can't you have different
login pages for SSO (really, corporate) and non-SSO (really, personal)?

If you have a B2B product where your customer provides an IdP for their users,
then provide them with a login link that is tuned for corporate users - e.g.
example.com/login/sso. On this page you have a single input box for an email
address. Most corporate users will simply bookmark this page and never know
that another login page exists.

If you have individual users, then have another login page - say,
example.com/login, with a prompt like "<Button for FB login> <Button for
Google login> <Button for Apple login> <Button for Corporate login> Or, enter
a username and password below: <username field> <password field>". If the user
clicks <Button for Corporate login> then it takes them to
example.com/login/sso. If the user has a corporate SSO but tries to fill in
the password field anyway, process the login request according to the
corporate IdP while throwing out whatever was in the password field.

~~~
pedrogpimenta
I think having two different login pages for the same thing (the service) is
worse than having two-step logins. It's just more confusing and requires you
to think about it before logging in, which should be super easy and quick.

------
bouke
So what would be a good solution when you offer both email/password as well as
multi tenant SSO as login methods? I want to cause as little friction, so that
would exclude a separate page/url for SSO logins. I could off course remember
the user's email the first time, and offer SSO subsequent logins if cookies
persisted. However, what to do about the first login? Most of the users will
continue to use email/password, and I wouldn't want to show the password field
to users that will be going to use SSO. So the password fields need to be
conditional on the email (domain). I don't want to hardcode the SSO domains in
the login form, so some roundtrip to the backend would be required. I see
little option except for separating into two steps. A hidden password field
would accommodate password managers and a cookie could remember which login
flow was used previously and conditionally show the password field. What are
your thoughts?

~~~
joshuak
Create a bloom filter of your SSO domains. As the email field is populated
check the domain against the bloom filter. If it matches disable the password
field and display a message about that domain using sso and the user being
redirected. In all other cases use normal password authentication.

In the background use an ajax call to your server to validate the bloom
filter. If you got a false positive then revert the UI to the password enabled
version, but this will be extremely uncommon with the right size of bloom
filter.

~~~
hirsin
Are you suggesting that the bloom filter be pushed with the login page? That's
like 10 MB of data on every login request. It's almost certainly faster to
just do the Ajax call. (Assuming you have around 2 million domains supported -
even at 200k that's over a megabyte).

~~~
CaptainMarvel
That doesn’t sound right. At 1MB for 200k domains is 5 characters per domain -
the efficiency of that bloom filter is “almost” like sending the domains
themselves. An online calculator suggested 230KB for a bloom filter of 200k
items (1% error rate).

~~~
hirsin
Yeah, 1 percent is way too high is the concern. That will generate support
calls and customer complaints. (plus, the same domains will always hit the
problem, meaning those domains will specifically ask us to fix it - so... We
send an extra list of known domains?)

------
wastedhours
As long as it still works with a password manager, the two-step process
doesn't really annoy me. What does is when these break the password manager
flow for some reason - I think that should be added to UAT for these sorts of
deployments now (especially considering browsers are coming built in with
these tools now too).

------
newscracker
IIRC, O'Reilly's Safari Online did a good enough implementation that handled
external authentication (using SAML with an IdP) and on-platform
authentication (using email address and password). The login form had both the
email and password fields, but once you typed your email address and tabbed to
the password field, it would've detected at that time whether you're an SSO
user who needs to be redirected to elsewhere for authentication, and if so, it
would hide the password field and redirect you when you hit Enter or clicked
the Submit button. This requires JavaScript to work, but seemed like a good
enough compromise to support both modes.

P.S.: It's been a long time since I used Safari Online. Hence the past tense
in the description above. It probably still has the same behavior.

------
sparker72678
I really hope this trend reverses soon.

------
thebigspacefuck
Google's login is especially annoying if you're used to typing username-tab-
enter-password-tab-enter. It takes you to the "Forgot Password?" page and next
thing you know, you've entered your password in plain text in the e-mail
field.

------
moltar
I hate this trend. It breaks password managers. Calendly is another service
that does this.

~~~
moltar
A solution maybe is to have a second page for password managers. Maybe there
should be a standard meta tag with a link to password manager friendly login
page.

------
pintxo
The article itself points to the relevant HN discussion:
[https://news.ycombinator.com/item?id=19172225](https://news.ycombinator.com/item?id=19172225)

------
stcredzero
The questions to ask in these situations and about security policy:

1) Are you increasing user friction?

2) Have you significantly reduced the workload of the attacker?

If 1) is yes, then it should be a no-go. A certain baseline amount of user
friction is necessary for security. However, any additional friction is going
to result in overall worse security for the site. You _want_ your users to be
using properly implemented password vaults. Don't get in their way.

If 2) is no, or "only in obscure circumstances," then it's a no-go. Cost-
benefit doesn't work out. See 1)

------
ivan_gammel
It would be great if article would mention a potential security issue with
this approach: two-page login forms, which have any conditional logic based on
the provided username, may leak the information about existence of that
username. This opens possibilities for social engineering attacks (“pay
$100500 or we’ll tell your wife that you are registered on the dating
website”).

EDIT: updated my comment to reflect that conditional logic may expose
existence of account, but does not necessarily do it.

~~~
dchest
You can't avoid it, username existence is easy to check by trying to register
an account. The only solution against the problem you described is to use
usernames, which are freely chosen by the user or generated by the website
automatically, not email addresses, so that people can create accounts not
tied to their identity.

Also, two-step form doesn't mean that you have to check username existence
after the first step. But, again, this is useless as mentioned above.

~~~
ivan_gammel
It’s not always like that. For non-digital businesses account registration
flow can be significantly different and not accessible for random visitors.
E.g. healthcare provider may provide online access to patient file only after
the first appointment.

------
thomasfedb
Twilio's login form commits this sin, but goes further and tosses in a
baffling "Enable 2FA" checkbox for good measure.

~~~
daveFNbuck
This checkbox is extra confusing because it enables 2FA for all users. I'm not
sure how everyone else gets credentials when you do that, so I unchecked it
after I figured out what I had done. Luckily, I kept the credentials in my 2FA
app because someone else later re-checked it.

------
bouke
TL;DR: To support SSO (SAML) that doesn't require a password. Good login forms
don't necessarily confuse password managers.

~~~
guntars
It can be made to work with password managers by using a hidden password
field, they just.. didn’t.

~~~
OJFord
Or an SSO button, or a different login page (that's very common), or ...

------
Waterluvian
Backblaze does this too. I hate it.

------
_Codemonkeyism
To break password managers :-( I hate 2 step forms. They make the internet
less secure.

------
dec0dedab0de
I was ranting about this the other day. The whole point of programming is to
have as few steps as possible.

While we're at it, can we also say forcing 2nd party apps to use Oauth is
nonsense that doesn't help anyone do anything.

~~~
ceejayoz
The linked article explains _why_ the second step is necessary.

~~~
dec0dedab0de
It also gives examples of much better ways to solve the same problem.

~~~
ceejayoz
It specifically calls the other options out as less suitable for SAML users or
having other downsides.

Option two: "This option prioritizes handling username/password login, and may
work better with password managers, but requires some Javascript handling that
could be fickle."

Option three: "It simplifies the page, doesn't require a lookup of the domain,
but could be clunky for the platform's SAML users."

Twilio is clearly _aware_ of the other ways of handling this.

------
cocochanel
Login pages nowadays are like a US airport.

------
kaivi
Whatever reason, this practice needs to die in a fire.

------
TeMPOraL
To confuse password managers, obviously. :).

------
gsich
I hate that shit.

