Hacker News new | past | comments | ask | show | jobs | submit login

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.



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.


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.


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.


What if it worked the other way and the password field was revealed when required vs hidden when not?


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.


You're forgetting the SSO use case.


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?


"Why do I have to enter my password twice?"


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.


This doesn't play nicely with password managers. They instantly populate both fields, and then you hide/replace one of the populated fields.


Here's a really fun edge case:

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.


Yes, they could. I can't remember where I've seen that - maybe okta or oneLogin?


Option 2 in the article


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.


"dont send password to server if sso radio box is checked"


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.


The bad guys can do exactly the same in the workflow where you redirect them rather than update the page.


They show an example of that in the article.


Not with the blanking (to prevent password leakage)


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.


Use client side hashing. With every page requiring Javascript it's no excuse to send passwords in plaintext.


Nice! That is a good reason to put them on two pages, and actually enhances security, based on your description of the use-case.


If so, how many users get advantage of it to trade off the others who use password manager?


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


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...


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.


Then I complain to them that their site is garbage.


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.

Which of us is happier?


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.


I'm happier never thinking about logins. And I don't have to. My misery of uncertainty is elsewhere in life.


It sounds like a hack that most regular users would never know about or do.


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.


Use the browser plugin?


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.


You store all your passwords in plain text on your machine?


Just some, which is no worse than saving them in a browser.


Chrome 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.


You can just open the browser and look at the saved passwords in the settings. A little bit harder I guess.


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.


At least in Chrome if you want to view the passwords; it asks you for Windows account password.


Chrome now requires your machine login to do this (on Windows at least where I tested it.)


I 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.


But 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.


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.


Is it tab compatible?


Nope... that would break accessibility for visually impared users.


Get rid off it then.


It's not visible, and disabled for aria navigation... it's literally just there for password managers.


With that I meant the two-page login. It's an abomination that plagues so many sites.


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 don't mean browsers doing it, but external password managers, like Keepassxc mentioned in another comment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: