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.
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.
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.
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.
This might be a factor of having been done just this year. A year back, the decision might have broken the other way.
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.
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.
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.
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.
(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)
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.
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.
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:
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.
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 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.
Which of us is happier?
Firefox uses a weaker scheme, but the passwords are still encrypted and it's definitely less accessible for an intruder compared to a plain text file.
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.
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 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!
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.
"login in with email/password", "login in with $SSO".
You'd really think these would be companies that would make a better job of this sort of thing - 'tech 4 tech' companies if you will.
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.
Perhaps there's some other threat I'm missing?
If it's one screen I can just prefill both at once.
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.
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).
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.
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.
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 ?
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.
This is a super easy way for attackers to enumerate valid email addresses to then come back and stuff credentials.
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.
We measured a 20% loss in users per click for the previous sign-up flow. That was quite a shock to see.
I have many passwords configured with:
1. Type username
2. Type <ret>
3. Pause 750ms
4. Type password
5. Type <ret>
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.
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."
Did you ride the bus today? Did you notice whether they removed one of the ads you saw yesterday? Yeah, neither did I.
These are pretty good signs it's at best useless and at worst harmful.
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.
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.
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.
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.
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)
EDIT: updated my comment to reflect that conditional logic may expose existence of account, but does not necessarily do it.
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.
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.
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.