15 ms·
Why are the username and password on two different pages?
- thomasfedb 7y agoTwilio's login form commits this sin, but goes further and tosses in a baffling "Enable 2FA" checkbox for good measure.
- daveFNbuck 7y agoThis 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.
- afandian 7y agoOn 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.
- sparker72678 7y agoI really hope this trend reverses soon.
- jsf01 7y agoThis 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 ago
- 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.
- TeMPOraL 7y agoTo confuse password managers, obviously. :).
- pintxo 7y agoThe article itself points to the relevant HN discussion: https://news.ycombinator.com/item?id=19172225 https://news.ycombinator.com/item?id=19172225
- timw4mail 7y ago...because apparently implementation details have trumped usability. 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.
- hn_throwaway_99 7y agoI 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.
- hrktb 7y agoIn 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 ?
- hn_throwaway_99 7y agoSure, 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.
- Waterluvian 7y agoBackblaze does this too. I hate it.
- bouke 7y agoTL;DR: To support SSO (SAML) that doesn't require a password. Good login forms don't necessarily confuse password managers.
- cabaalis 7y agoI'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.
- Consultant32452 7y agoA script can easily query your bank website and show you the same image.
- wool_gather 7y agoYep, or even simpler, just show a generic "broken image" image, that most folks would probably brush off as "stupid computers never work right anyways".
- plibither8 7y agoAnd for the statement, a "Loading..." should be sufficient, since most folk don't have the patience to wait for the statement to "load" and verify it.
- maxxxxx 7y agoI 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.
- ceejayoz 7y ago> I've seen banks do this and am starting to see it in healthcare. These are pretty good signs it's at best useless and at worst harmful.
- kstrauser 7y agoThey'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.
- greggyb 7y agoI 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.
- robk 7y agoExcept 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
- greggyb 7y agoWhat 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.
- stronglikedan 7y ago
- echelon 7y agoI hope someone from Twilio engineering or product management reads the complaints here and actually redesigns their login flow. Multi-step login flows are trash.
- OJFord 7y agoBackblaze too. 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.
- kaivi 7y agoYep, logging in to Backblaze is a PITA, in addition to their unreasonably short-lived sessions.
- atYevP 7y agoYev 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).
- OJFord 7y ago> 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. Perhaps there's some other threat I'm missing?
- kosievdmerwe 7y agoEspecially on iOs, where I have a password manager that won't fill in the email/username step, so I have to manually either find that or type it. If it's one screen I can just prefill both at once.
- intellix 7y agoGoogle 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
- kaivi 7y agoWhatever reason, this practice needs to die in a fire.
- deleted 7y ago[deleted]
- immemorial 7y agoOnce Google started doing it, it creeped out in all directions. The SSO reason is 1000% the driver behind it. None of the other reasons really succeed in rationalizing all the added complication. It's just retcon after the SSO need. Others are worse. Microsoft has ten layers of cognitive dissonance gumming up their login. Worst of all, they have these check boxes, where I indicate that I want them to remember my choice, and what "remembering a choice" seems to mean many things to many people. To Microsoft, "remembering a choice" means tripping a flag on an ephemeral cookie that does not leave the browser on the computer I'm using when they show me the check box. Indeed, if I change to some other browser, but log in with the same account, the thing they were supposed to remember never attaches to the user's account. It only gets "remembered" by the HTTP session that displayed that particular instance of the checkbox, and only if you never clear your cookies. A "client side only remember my choice" checkbox. Now, why the fuck would they even bother wasting my time with that? Why get my hopes up? Are they trying to torture me? Is it a taunt that the checkbox is always defaulted to the opposite of what I want? If they show me the checkbox, after I indicate the use account, why can't they attach that choice to the user account? Do they simply hate me? The psychological warfare being deployed in that situation speaks volumes to me. It tells me that the person who chose to put the checkbox there, that person didn't really care if it did anything. It tells me that there was a conversation between a boss and employee, somewhere in this version of the time stream where John Connor beats the terminator and Skynet doesn't initiate judgement day, and in this version of events, the employee built something that made sense, and the psychotic boss passive aggressively told the employee to detach the option from the user account, and make sure it only binds to the cookie. The bastard can only have done this to both torture the employee AND disappoint untold millions of users who expect a checkbox that advertises memory to actually remember them. It never does. It doesn't remember anything. It lies to you. It forgets. This is why I hate Microsoft.
- wastedhours 7y agoAs 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).
- dec0dedab0de 7y agoI was ranting about this the other day. The whole point of programming is to have as few steps as possible. 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.
- ceejayoz 7y agoThe linked article explains why the second step is necessary.
- dec0dedab0de 7y agoIt also gives examples of much better ways to solve the same problem.
- ceejayoz 7y agoIt 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.
- Bootwizard 7y agoI 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.
- moltar 7y agoI hate this trend. It breaks password managers. Calendly is another service that does this.
- moltar 7y agoA 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.
- newscracker 7y agoIIRC, 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.
- CaliforniaKarl 7y agoI 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!
- hrktb 7y agoThe 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.
- simongr3dal 7y agoThe 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".
- ivan_gammel 7y agoIt 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.
- dchest 7y agoYou 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.
- ivan_gammel 7y agoIt’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.
- bouke 7y agoSo 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?
- joshuak 7y agoCreate 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.
- hirsin 7y agoAre 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).
- CaptainMarvel 7y agoThat 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).
- yellowapple 7y agoI 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). [1]: http://bradfrost.com/blog/post/dont-get-clever-with-login-forms/ http://bradfrost.com/blog/post/dont-get-clever-with-login-fo...
- tracker1 7y agoCurrently 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.
- gsich 7y agoI hate that shit.
- urda 7y agoThis is the worst. It often requires two invocations of your password manager program to fill two pages out back-to-back. Just put both on a single page, quit trying to be cute web devs.
- bollybob123 7y agotwilio is too expensive . You should try https://textita.com https://textita.com
- thebigspacefuck 7y agoGoogle'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.
- stcredzero 7y agoThe 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)
- _salmon 7y agoIf 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.
- _Codemonkeyism 7y agoTo break password managers :-( I hate 2 step forms. They make the internet less secure.
- cocochanel 7y agoLogin pages nowadays are like a US airport.
- solatic 7y agoWhy 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.
- pedrogpimenta 7y agoI 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.