10 ms·
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 i
by jsf01 7y ago
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.
- davemp 7y agoMy 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 agoLet 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 agoOnce 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 agoYes, they could. I can't remember where I've seen that - maybe okta or oneLogin?
- basch 7y agoOption 2 in the article
- isostatic 7y agoNot 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 agoThey show an example of that in the article.
- isostatic 7y agoNot with the blanking (to prevent password leakage)
- SilasX 7y agoNice! 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 agoIf so, how many users get advantage of it to trade off the others who use password manager?
- kijin 7y agoIn 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 agoIsn'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 agoThe 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 agoAs 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 agoUse client side hashing. With every page requiring Javascript it's no excuse to send passwords in plaintext.
- joshuak 7y agoThat 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 agoHave 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 agoGood 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 agoMicrosoft’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 agoI don't think this is the case. My twilio login seems to expire fairly often and I have to sign in a lot.
- AsusFan 7y agoDefine "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-Custom-Sequence#delay-n https://github.com/keepassxreboot/keepassxc/wiki/Autotype-Cu...
- goshx 7y agoIt sounds like a hack that most regular users would never know about or do.
- jimmaswell 7y agoI 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.
- fwip 7y agoYou store all your passwords in plain text on your machine?
- jimmaswell 7y agoJust some, which is no worse than saving them in a browser.
- ahje 7y agoChrome and Edge uses the OS' own storage mechanisms for passwords (Safari too?), and that's considerably more safe than a plain text file. 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.
- tracker1 7y agoI add a hidden password input (opacity/size, not display:none), so that an auto-filled value can carry forward if it's not an SSO account.
- Mirioron 7y agoBut if I don't know that it's there I'm not going to trigger autofill because I don't know where my password could end up at.
- tracker1 7y agoThat'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.
- gsich 7y agoIs it tab compatible?
- shmerl 7y agoAutofill 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.
- clintonb 7y agoBased 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.
- shmerl 7y agoI don't mean browsers doing it, but external password managers, like Keepassxc mentioned in another comment.