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.
We have customers that have accounts on our platform, but are authenticating through their own SAML Identity Provider (I call this authentication delegation). We don't have any password on our platform for these accounts: we redirect the user to the 3rd party authentication when we detect that the email has an authentication delegation.
The issue is that their users come to our platform through our login page, enter their email, and then enter their corporate password in our password field. The login obviously fails (because we cannot verify their password), and we redirect the user to their corporate authentication page, where they can login. This is a security issue because we have to explain to their users that they shouldn't enter their password because they are leaking it to us... which is complicated to justify.
So what we did (and what twilio, microsoft and google did) is separate the email and password in two steps, so that:
- standard users have 2 steps to login, we can verify their passwords, all is good
- delegated users enter their email, we check how to authenticate them, and redirect them to their own login page
I suspect 90% of the split logins like this are due to that "password isn't needed" issue. Twilio dangles the security check in their article, but in reality this is to accomodate big corporate clients.
Also, don't do it like microsoft: you enter the email, type "TAB" to go to the password, and the page disappears under your nose and goes to the IdP page without any hint at what happened.
That helps a lot to understand why this happens, thanks.
However, as you can see, many many people see it as a usability problem. The core issue is selection of action based on the account (not user, the user may have multiple accounts) being of a particular type. This mistake is you are attempting to hide the selection from the user perhaps with the intent of making the process easier / less obtrusive.
From a UX point of view I'd say you need to do the opposite, make the selection obtrusive i.e. clear and obvious to the user. Either in the presentation, by explaining what you are doing, or in the functionality by doing the membership selection client side perhaps with a bloom filter, or presenting "corporate", "individual" tabs so that one starts with the correct interface.
Most people are use to the idea of a work or school account vs a personal account, I think just giving users a short explanation and a choice would be MUCH better then this "clever" auto redirection that doesn't make any sense on the face of it.
Have you validated this theory against actual users?
Because I have. Users do the wrong thing. Constantly. Every single chance they get. There is no level of education that can fix it. Users don't want to do the right thing, they want it to just work with no thought required.
Every option you present to users is one additional source of support calls, frustrated users, and frustrated account managers wondering why you're making things so hard for the users belonging to customers they work with.
So my company split its authentication page in two also. It results in fewer support calls and fewer complaints to the account managers.
And for what it's worth, it works with most password managers too. Anyone having trouble with that should consider a different option. It's not like there is a shortage.
Good point, and I agree as for not putting the burden on the user, that's why personally I'd used the bloom filter approach to quickly disable password input (not remove the field) and display a short explanation for the redirect.
Normal users would see nothing out of the ordinary, and SAML users would see what they see now plus an optional explanation for what's going on.
I have received my fair share of confused calls regarding (microscopically) more arduous login processes and presenting fewer people with any change at all helps tremendously with reducing those calls.
I admit, I had some concerns about that as well. But our UX team and PMs did user surveys they believed to be broadly representative and found that enough sites are doing split logins now that our users didn't have any trouble with the change.
This might be a factor of having been done just this year. A year back, the decision might have broken the other way.
In this age of single-page web apps, it's preposterous to suggest that one needs to navigate to a second page to do something as simple as entering one's password -- regardless of what's happening under the hood.
Add some AJAX to that damn thing. You don't need to pull off a microsoft and redirect without notice. It can be as simple as hiding the password field and showing a button for the 3rd party auth provider instead as soon as the user enters their email. Payment forms have perfected this kind of technology a long time ago; they can rearrange the form to suit the card type as soon as you enter the first few digits of your CC number. There's no reason login needs to be any more clunky.
As another commenter said, that solution leaks security information - it says "this domain is a customer of ours and is configured to use a special authentication setup." Some big and lucrative customers will object to this leakage. Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect.
An AJAX solution can still be the right tradeoff of user experience vs security for some sites, and the article gave a couple of examples of major sites that have followed your suggestion. But the security downsides mean it's not right for every case.
Agreed... My plan is to wait 1/2 second before processing any login, and add a bit more for failed attempts before lockout. Random amount of time between windows.
I've thought about doing a client-side challenge token and subtlecrypto to pbkdf2 that to generate a key, then sign the login request with the generated key. I could use a pool of precomputed keys on the server and associate the key source sent via http-only cookie for the key's id in the DB. Unfortunately still have to support the non-chrome edge browser which seems to have some gaps in browser crypto support.
> Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect.
You could rate limit based on IP, or even in the javascript, if you're that concerned -- .onblur sends the request, which typically responds quickly with a "password not needed" flag. You're just trying to stop casual snoopers, as for scripts it's not much different to sending the request as part of the entire form (and seeing if the response is a page or a redirect)
That information is leaking anyway. Besides, a smart attacker ain't waiting for page loads, he's got scripts. It's all security theater. If a corporate customer insists on objecting, maybe you could charge them $$$ to add a special case for their domain.
Many corporate clients don't want you passing their users passwords through your backend, so full page navigation is required. You're also working with on-premises Auth servers that likely don't support whatever fancy front channel protocol you'd propose to make this happen.
There is no correlation between "full page navigation" and "not passing users' passwords around". Full page navigation is only needed for on-premises auth servers that require a redirect, and the server can easily tell which users need it as soon as the username is typed in. Give them the redirect they want. Everyone else gets a better UX.
Ah, yes, figure out which ux the user needs before they tell you who they are. Please, let me know if your genie is for rent. Otherwise, see other comments for how the detection ux with a default password entry caused issues for us.
Isn't that all done on the client? Soon as you require a HTTP response on potentially a slow connection it's no longer instant and a poor user experience.
The default should be to show the password input for normal users. Chances are, most corporate users are 1) using a fast connection paid for by their employer and/or 2) used to shitty stuttering UI, so it will be less of a problem if it takes a couple of seconds to load their 3rd party auth provider.
If the number of auth providers are small and tied to specific domains in the email address, perhaps you could speed up the process by pre-loading a hash table of domains => auth providers.
Once they enter their login, couldn't you check if it's a delegated login, and hide/replace the password field before they start to enter it?
(i.e. replace it with a div saying "you will be redirected to your corporate login page to complete authentication" to avoid the "without any hint" issue)
We (Microsoft) did that for a while. It doesn't work as well as the paginated flow. Users without a password get to the page and leave, claiming they don't have a password and are stuck, because they don't try to type in their email.
As others have mentioned, this isn't great for accessibility. And most password managers would be smart to ignore hidden password fields, since that's a decent attack vector for skimming.
This really borks in terms of accessibility, as the huge change as a result of an onblur event will be awkward. Also, it will require JS to do so, so simple post is no longer an option. Of course the system I'm working on won't work without JS and a modern browser anyway.
What if password fields had a "bitbucket" mode where they swallowed all input and overwrote it with "xxxxxxxxxxx"? Then instead of "a huge change" from an onblur event, when the email is checked for login type, conventional username/password users just have their password field turn off bitbucket mode. No one reveals their password to the provider. Everyone is happy -- but only in this hypothetical future world where browsers have this new functionality.
How? In that case, some people come along and manage to enter their password, perhaps because they didn't enter their login or email first. The bitbucket entry field soaks the information up, and it's never revealed. Most of the time, when they enter the login, the password field can disappear in that case. Or is there something I'm missing?
Probably the solution is the other way around. Start with a password field, but keep it hidden - that way, password managers can autocomplete it (and submit the form with username & password immediately), but humans won't see it, so won't be entering passwords from different sites...
If it's not a password my code should see, I would rather it not be entered into even my client side code. That makes it potentially accessible should I have a bug, eg XSS.
My federated (AAD) login for msft work things (Azure portal, O365, some VSTS) is <username>@<company>.com.
My non-federated login for other msft work things (down to a couple old VSTS accounts that aren't migrated yet) is <first.last>@<company>.com.
So when I enter my username for non-federated things, it has to ask me whether to forward to AAD or prompt for a password. Because my login ID looks like it should be federated, but doesn't actually exist in their upstream.
Not quite. That still has the field open, which could still be filled in. The ajax call could blank the field (even if it's been filled in already), preventing the password from leaving the browser even accidentally.
Yes, but if they did they are giving away security information: they are acknowledging that the entered email address is a legit delegated login. That's a bad thing to do, security-wise. You don't want bad guys to start trying email addresses and be able to see which ones are good email addresses.
Microsoft’s approach sucks. Totally breaks password auto fill on iOS.
I talked to them at Build and the response was basically ‘fuck you passwords are dead’ which I guess is fine except they clearly aren’t. It was particularly infuriating in the context of everyone else doing it right.
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.
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.
> 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.
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.
I just spend <1 minute to update the login procedure for that site in my password manager and don't think about it again, continuing to log into all sites the same way, with a hotkey to perform auto-type for that site.
High-pedantry groups like programmers are odd, in that they display this emotional state where they have nothing but complaints about how crappy the world is, yet they seem inwardly smug and happy about how they're clever enough to know better. Is that misery? Is that happiness? I'm in one of those groups, and still, I don't really know for sure.
Was an avid user of kpxc for a year. The auto type feature did not feel secure compared to other pwm's. It requires the username input field to be focused, and if the wrong field is focused (click didn't take?) or otherwise changes mid-type it spills your credentials into the input and sends them. Other managers seem to at least try to validate the entry types.
I do this stuff manually in autohotkey for flows like tabbing to the MFA app window, clicking the right place to copy the code, tabbing back into the app I'm trying to log into, clicking the right space to get to the input fields, and entering the username/password/mfa. As well as for logging onto a website where I need to enter the username, hit tab, hit enter to select "log in with password", then enter the password and hit enter again. Saves a lot of time/dealing with typos in the unnecessarily complex passwords these systems require and it's cool to watch it do it.
If you set a master password for saved logins in Firefox then passwords won't be available with a simple click, and they will be encrypted on disk.
In browsers that use the OS' password storage then they will normally be stored in encrypted form, although the browser integration is seamless so you won't notice the difference.
In both cases, there is a significant security advantage in cases where the data on disk is leaked (say, if someone steals your computer and you don't have full-disk encryption.
That's fair, unfortunately, displaying the password field and for SSO users triggering onblur would be weird accessibility and weird behavior... though better for user/password accounts. Also, as mentioned in TFA does allow for captcha for a non-2fa account as a catch step with the password.
Autofill sounds convenient, but it's actually a dangerous feature. You can by mistake change focus, and autofill your password into some public post, because you don't have an extra interruption between user name and password being entered.
Based on my usage only password fields get the password. Unless the site improperly marks up a password field, browsers won’t auto fill.
While typing this on Chrome for iOS, I attempted to fill my password in this text area. Chrome will not let me, and posts an alert informing that the field is insecure.
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!
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.
The solution seems pretty pbvious, and it's in use on pretty much every smartphone app. Just have more login buttons that can lead you to the right page.
"login in with email/password", "login in with $SSO".
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.
Yev here -> we're taking a look at the sessions and possibly implementing a "hey are you still here"-type thing that a lot of banking institutions use. The thought being, if you've logged into your Backblaze account and left the computer open and unmonitored folks have access to your data (granted they also have access to your computer - but you can log in to Backblaze from any device to do restores - so we went with short-ish sessions).
They're not 'short-ish', they're shorter than... every actual 'session' I have with the site.
They're so short that I've been checking cookies and wondering what I'm blocking that's breaking it until I saw other comments here.
There doesn't seem much utility to me in having the website session expire before the screen locks - apart from anything else the computer quite likely has B2 keys or the consumer app installed if it had the website logged in.
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.
I just checked with the native password manager, it offers to auto fill the username after using touchid and when you click next it does the same with the password field.
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).
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.
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.
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.
In this case the issue is not just the trade-offs but also messing up an existing paradigm.
I’m of the opinion that going against the status quo needs extra justification, and in this case the arguments are arguably weak (there are implementations that don’t break the well know user flow, and no alternative has an overwhelming advantage over the others)
Basically we’re stuck with sites that broke the original frame of reference without bringing a much better alternative.
Sure it’s a business requirement, but executed poorly. Can’t we be upset about it ?
Sure, you can be upset about it, but then at least let's make the argument about "What is the best way to solve this business problem?", instead of pretending this business problem doesn't exist.
For example, you argue that this "breaks an existing paradigm", but I'd argue that auth with just username and password is so fundamentally broken that a new paradigm is needed in any case, and things that push us more towards passwordless/token/key based auth is a step forward.
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?
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??
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.
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.
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
In Auth we call this a NASCAR, where there are so many buttons on the page that the user no longer knows which one they used to login last time. This leads to retention problems as users accidentally sign up for your app multiple times, ending up with their data scattered in multiple spots.
If usability is your goal, and I'm an SSO user who literally doesn't have a password, a form with a password required on the first step is going to be pretty unusable.
No user will understand that. They will call their IT admin and ask for the password. Or won't type the password and think you should find it somewhere else. Or think it's I secure because anyone can sign into their account without a password.
Make a background call to check whether a password is used for the given email, and hide the password field if so. There will be a delay, but if they’re confused that gives plenty of time to do this.
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.
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
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.
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
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.
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.
Sure. I was responding explicitly to concerns about multi-page login workflows breaking password managers. My response is about using a password manager that can support these login workflows.
The layman is not concerned with the issue I was responding to. I agree with you that the login forms should be better. But I am making a point that "it breaks my password manager" can be answered with "get a better password manager, or learn better how to use yours."
My point is that it does break password manager workflows, since you have to go above and beyond the comfort level of a layman to circumvent the broken login workflow.
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.
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.
I usually forget that image anyway and I think that most people will have no clue what to do if the picture is right or wrong. I bet they will go ahead anyway.
Yep, or even simpler, just show a generic "broken image" image, that most folks would probably brush off as "stupid computers never work right anyways".
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.
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.
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.
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?
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.
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).
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).
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?)
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).
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.
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.
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.
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)
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.
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.
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.
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.
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.
