14 ms·

My tin-foil theory is that the two pages are only there to add more friction relative to just keeping their login cookie at all times.

by davemp 7y ago

xgbi 7y ago
Let me explain why we did it: 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.
- isostatic 7y ago
  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)
  - lazyasciiart 7y ago
    Yes, they could. I can't remember where I've seen that - maybe okta or oneLogin?
    - basch 7y ago
      Option 2 in the article
      - isostatic 7y ago
        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.
        basch 7y ago
        "dont send password to server if sso radio box is checked"
  - deleted 7y ago
    [deleted]
  - ViViDboarder 7y ago
    They show an example of that in the article.
    - isostatic 7y ago
      Not with the blanking (to prevent password leakage)
  - tomp 7y ago
    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...
- SilasX 7y ago
  Nice! That is a good reason to put them on two pages, and actually enhances security, based on your description of the use-case.
  - a012 7y ago
    If so, how many users get advantage of it to trade off the others who use password manager?
- kijin 7y ago
  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.
  - goguy 7y ago
    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.
    - kijin 7y ago
      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.
  - jkaplowitz 7y ago
    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.
- gsich 7y ago
  Use client side hashing. With every page requiring Javascript it's no excuse to send passwords in plaintext.
- joshuak 7y ago
  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.
  - chowells 7y ago
    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.
    - joshuak 7y ago
      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.
- nxc18 7y ago
  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.
333c 7y ago
I don't think this is the case. My twilio login seems to expire fairly often and I have to sign in a lot.

My tin-foil theory is that the two pages are only there to add more friction relative to just keeping their login cookie at all times.

by davemp 7y ago

My tin-foil theory is that the two pages are only there to add more friction relative to just keeping their login cookie at all times.

xgbi 7y ago

Let me explain why we did it: 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.

isostatic 7y ago
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)
- lazyasciiart 7y ago
  Yes, they could. I can't remember where I've seen that - maybe okta or oneLogin?
  - basch 7y ago
    Option 2 in the article
    - isostatic 7y ago
      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.
      - basch 7y ago
        "dont send password to server if sso radio box is checked"
- deleted 7y ago
  [deleted]
- ViViDboarder 7y ago
  They show an example of that in the article.
  - isostatic 7y ago
    Not with the blanking (to prevent password leakage)
- tomp 7y ago
  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...
SilasX 7y ago
Nice! That is a good reason to put them on two pages, and actually enhances security, based on your description of the use-case.
- a012 7y ago
  If so, how many users get advantage of it to trade off the others who use password manager?
kijin 7y ago
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.
- goguy 7y ago
  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.
  - kijin 7y ago
    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.
- jkaplowitz 7y ago
  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.
gsich 7y ago
Use client side hashing. With every page requiring Javascript it's no excuse to send passwords in plaintext.
joshuak 7y ago
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.
- chowells 7y ago
  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.
  - joshuak 7y ago
    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.
nxc18 7y ago
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.

333c 7y ago

I don't think this is the case. My twilio login seems to expire fairly often and I have to sign in a lot.