Oktane20: Authentication UX Anti-Patterns
Transcript
Details
Kelley Robinson: Hello, everyone. I am prerecording this talk from Portland, Oregon, and I hope that you're having a great day from wherever you may be quarantined. Like most of us know, a good user experience is a key part of any successful authentication implementation. And while this talk discusses a lot of things that you shouldn't do, I hope that you take away some best practices for designing and improving your own site or application auth. Authentication is one of those disciplines like dev ops or public health services, where most people aren't going to notice when you're doing your job well, but they sure will notice when things go wrong. So one of the goals here is to make sure that your users don't notice your authentication. And if you do that, you're probably doing something right.
Kelley Robinson: It sure definitely shouldn't frustrate your most security conscious users. You definitely don't want them tweeting about your password policy, but if you do want to raise your own blood pressure or at least get a good laugh, I encourage you to check out this Twitter account. It's called Password Too Strong. It shares a lot of frustrating things like this one where whatever this Iberia site is, the password can only contain six characters, which is just going to be a bad policy. But even if you implement reasonable measures like this one that enforces that passwords don't contain personal information, make sure that those rules work like you expect them to, and that you're not causing frustration to your users like Stefan saw here. And this is a lot of what we're going to discuss today, things to avoid so that your users get to their protected assets seamlessly and don't get frustrated along the way.
Kelley Robinson: My name is Kelley Robinson. Hello, everyone. I work at Twilio. Twilio is a company that provides communications APIs, and customer engagement to a wide variety of businesses. We're known for our APIs for things like SMS and voice and email specifically, I work on our account security side of the business. So, if any of you have heard of Authy or use the Authy app, Twilio acquired Authy about five years ago and I work on our authentication APIs for things like phone verification, email verification, and 2FA. I also spend a good chunk of my time on educating developers about security, especially authentication. And so this talk is going to incorporate a lot of the things that I've learned in the last couple of years, working with developers and customers on their authentication challenges. There are three main categories I want to break this into. First passwords, second two factor authentication, and finally account recovery, kind of in that order of the life cycle of authentication that we might find. I'm going to spend the most time on 2FA because that's where I spend the most of my time. But I also frame this to focus on consumer applications, just to note that a lot of these takeaways can be applied to enterprise or workplace environments, too.
Kelley Robinson: Let's start with passwords. Obviously the things that I'm going to cover here as anti-patterns are not a complete list of things that can go wrong, but a few of the anti-patterns that I want to highlight include first, bad support around password managers. Second, bad support for mobile or other platforms like TVs. And three, tangentially related to passwords, but definitely related to login is not offering options for your users to log in outside of SSO services like Facebook log in.
Kelley Robinson: I'm assuming a lot of folks in this audience use password managers. You are after all attending an authentication conference talk, but this is an easy win to make sure that you delight your security conscious users is making sure that your password form fields support password managers. And there's a couple of ways that you can do is really easily. First, you want to make sure that you're allowing pastable passwords. This seems obvious, but there's a lot of companies out there that are still hunkering down on this idea that not allowing pasting is a good way to prevent brute force attacks. And that they can use that as a way to increase the security of their sites.
Kelley Robinson: Unfortunately, that's going to frustrate a lot of people that use password managers as a way to secure their own accounts. So, some basic ways to support this is first and foremost, allowing pasting passwords, which is something that people will be quick to complain about. Next, you want to make sure that you handle the types of passwords that are commonly generated. In two exceptions that I see not supported most often include restricting special characters or enforcing some kind of length restriction. The example in this screenshot here is particularly hilarious because the semi-colon is listed as both an allowed and a not allowed special character, which is just kind of hilarious because this message is hard enough to parse already. So, definitely support password managers.
Kelley Robinson: Another anti-pattern is typing in passwords on not computers. And so this is related to supporting authentication on the increasing number of IOT devices in our lives. So you might recognize this issue from having to type in your Netflix password on a TV using that TV remote, or perhaps you're like Sylvia here and you have a Tesla that doesn't have a full keyboard. And so this is kind of related to a password manager problem, where if Sylvia had generated a strong password, using a password manager, then gets into her Tesla and is supposed to type in that password, but the keyboard there doesn't support special characters that's going to cause a lot of frustration.
Kelley Robinson: One way that folks have addressed this problem is by using other devices and other authenticated sessions to verify your login. Here's an example of how YouTube handles that. Instead of typing in a password on the TV, you can type in this one time passcode on a device with a better keyboard that you probably have on your phone, or you're logged in session on a computer. And so that's a really nice way to support this kind of login so that somebody doesn't have to use their TV remote to navigate to all the characters in their password in order to log into that session on a keyboardless device. So definitely think about the places that your users are logging in and how you can better support them, especially if there isn't going to be a keyboard involved.
Kelley Robinson: And finally, I wanted to mention only supporting third party authentication. And this is using things like single sign in with Facebook. This is one way to spread your risk. And it's definitely an easy way to get a site up and running quickly, but it can backfire if you don't offer options to your users. And one way that we saw this manifest was back in 2018. I don't really remember why people were mad at Facebook at this time, but people got especially mad at Facebook and were deleting their accounts en mass. So, a lot of dating apps that have implemented basic login as their only option for using the service had a lot of issues because their users were ... it was preventing people from signing up, it was preventing people from getting into their account, and it was ultimately affecting the number of people that were using their application.
Kelley Robinson: And so from this TechCrunch article, Bumble dropped the Facebook login requirement given the recent backlash to Facebook's insatiable appetite for user data, coupling dating apps with Facebook began to make some users very uncomfortable. And so what we started to see is dating apps like Bumble, deciding to support additional login methods, so they could support their users and that they didn't have this kind of one track path for people that were only being able to support by Facebook login.
Kelley Robinson: So, again, this is going to be an intentional trade-off and a choice that you're going to have to make. Maybe that makes sense for a prototype or when you're first getting your app off the ground, but once you have a large enough user base, you probably want to start supporting additional sources of login. That's a few things to keep in mind when implementing password based login. Supporting password managers, considering alternative devices, and supporting multiple forms of log-in.
Kelley Robinson: Next, I want to talk about anti-patterns with two factor authentication, also known as 2FA or sometimes multifactor authentication, which is known as MFA. I'll use those terms interchangeably here. A few of the aspects I'll address include not supporting 2FA at all, or not incentivizing 2FA. It's not much good if nobody turns it on. Also, implementing it in a way that allows users to lock themselves out. That's a problem that we see quite often. And finally this idea around 2FA paranoia and making sure that people still offer a variety of options and channels for adding 2FA. So, not only is 2FA another way to delight your security conscious users, it's becoming necessary for high value services, because unfortunately there's still a lot of people using passwords like 123456.
Kelley Robinson: If any of you are familiar with Troy Hunt's a site, haveIbeenpwned.com, it's a really good way to see the number of passwords that have been seen in data breaches and the password 123456 has been seen in like 22 million data breaches. We'd like to think that we're beyond this place where people are using insecure passwords, but it's inevitable that people will do this still. So, 2FA is one of the solutions that we've come up with to help decrease the amount of account takeover that we see. So, it really is up to you to decide whether or not your product is high value. Maybe if you're something like a pizza delivery service, it might not be necessary for you, but you also have to keep in mind that even pizza delivery services might have saved credit card information or a decent amount of PII attached, as names and addresses and phone numbers there that even if people aren't using that to use a lot of value or take a lot of money away from your service, they might be using that to verify identity on other services, so that they can do an account takeover on a banking or financial service somewhere else.
Kelley Robinson: But say you have the option to turn on 2FA. Another problem is if no one knows about it, doesn't turn it on, or if they're not incentivized to turn it on at all. And so it's one thing to even offer it, but if nobody uses it, that's also going to be a problem. And there's a lot of websites that are getting more savvy about how they're getting people to enable 2FA, so unless you're somebody like Coinbase, you probably won't make 2FA mandatory, but you have other options than just hiding it in the profile settings. Things like log-in prompts can be really effective at getting people to turn it on reminding people, this is an option that's available every now and then, but we know that strategies like product incentives work from looking at Google Trends for 2FA searches. Think to yourself, does anybody know what that spike in August 2018 was?
Kelley Robinson: This is 2FA Google searches interest in overtime in the US. That was when Fortnite decided to offer end game incentives for its users to turn onto 2FA. And this was huge. It was hugely successful, hugely impacted the amount of people that knew about 2FA as a authentication option, then knew about it and turned it on and used it for the first time. And now even almost two years later, when you look at the related search queries to just the term 2FA and Google, three of the top five related search queries have to do with Fortnite. Epic is the company that owns Fortnite there.
Kelley Robinson: It's a really good search query to 2FA. And Fortnite isn't the only ones that are offering incentives. That's obviously great if you're a video game, but a company like MailChimp offers a 10% discount for accounts that turn on 2FA. And so think about your business and what you could do to incentivize users. There's a cost associated with account takeovers, and you want to make sure that you are mitigating that as much as possible. Offering a discount or offering some kind of product incentive is a really good way to make sure that people are going to or increase the number of users that turn this on.
Kelley Robinson: So now you offer 2FA and you get people to turn it on. You want to make sure that people set up the second factor successfully, and this can be really difficult. And this is really where you want to involve a UX designer. Making sure that this process is set up in a way that makes user successful. And so I want to use this study from 2018 that focused on YubiKey, usability. YubiKey is, if you're not familiar, a form of multifactor authentication that allows you to use an external physical key as the second factor. And so they did a study that used these keys, so the same second factor was used across multiple platforms. And the setup success varied a ton depending on the platform. On Google, people were successful in setting ended up 83% of the time. And on Facebook, people were only successful setting up 32% of the time.
Kelley Robinson: One of the interesting things here is that 19% of people locked themselves out of Windows 10 because the system actually allowed them to enable the factor without ever doing a successful verification. And if you're familiar with YubiKeys and WebAuthn, and these types of authentication systems, a lot has changed in that arena since 2018, but this is a really interesting look at how the onboarding UX impacts user success. And so when you look at the percentages there, there was a common denominator here of the factor itself. So, that didn't change no matter where they were using it, but the site and the way that they had the onboarding flow to get that set up was the variable in this study. And so it does go to show that you can assume that Google had a much better user experience there because people were more successful at setting it up.
Kelley Robinson: And finally, I want to address 2FA paranoia as an anti-pattern. And what I mean here is that you are commonly hearing people that aren't willing to support a channel like SMS, people that say SMS is in the secure, that don't want to support SMS as a channel because of the vulnerabilities in it. And I get that. SMS isn't a secure channel. There's a lot of vulnerabilities in the telephony network and SIM swapping makes people incredibly vulnerable to getting their accounts over in that way. However, I think it's really important to note that SMS-based 2FA is still better than no 2FA at all. And this is something that I struggle with constantly because I'm constantly questioning that this is just my personal bias working for a company like Twilio, but there's research outside of my spirit to back me up on this one.
Kelley Robinson: There was a Google study in May, 2019 that showed that an SMS code sent to a recovery phone number helped block 100% of automated bots, 96% of bulk phishing attacks, and 76% of targeted attacks. While it's good to offer stronger factors like TOTP and push, you don't need to disable SMS. Even Coinbase, a company that arguably has a very, very valuable product behind it still allows SMS-based 2FA because they understand that any 2FA is better than none.
Kelley Robinson: And that's because, like the security researcher Cormac Herley says, "When we exaggerate all dangers, we simply train users to ignore us." And I love this quote so much because I think it's really important to understand that users are people, users are people that have other concerns in their lives. We can think about ... today, the people in the world around us have a lot of other concerns that don't have to do with two factor authentication or authentication at all. And so, when we start to exaggerate the dangers here, we just start freaking people out in a way that makes them unwilling to listen to reasonable advice.
Kelley Robinson: And finally, I want to talk about some of the best practices and things to avoid around designing account recovery processes. This is perhaps the hardest thing to get right. Since you're in many ways, no longer authenticating, but you're re-verifying identity. Who do you trust and how do you optimize for minimizing support costs? That's something that I didn't talk about already, but one of the things that you want to be measuring throughout this whole process, and when you're designing these systems is how do you increase user satisfaction or at least maintain user satisfaction with your product? Probably decrease the number of account takeovers that you're having, but also you want to relative to the cost of the account takeovers decrease the cost of support, because as you add additional strength factors and additional hurdles and friction to your authentication process, you're probably going to ... especially in a consumer application increase the number of support tickets that you get and increase the confusion from some users.
Kelley Robinson: And so you do want to make sure that when you're thinking about these things, that you are thinking about how you are going to support this and how you are going to mitigate that in a way that makes your user successful without having them need to call your customer success hotline. And so, one thing that I hate to see is when companies bypass the first factor entirely and allow you to recover only using the second factor. Again, this could be a conscious trade off that you've made, and that might be okay, but this leaves you incredibly vulnerable. Like we mentioned, SMS based 2FA isn't necessarily the most secure form of 2FA. If that's the second factor, that's great. But if somebody can gain access to the account without the first factor and can bypass that using only the second factor, that leaves you incredibly vulnerable.
Kelley Robinson: Some basic ways to support this is first and foremost, you want to make sure that you send notifications to all factors, especially the first factor. In this case, a lot of times we think of the first factor as your email. That's where you're getting a password reset sent to, passwords are generally tied very closely to that email address. If you do allow resetting your password through a phone number or through that second factor channel, make sure that you're at least notifying the user at that first factor. And then one thing that you can also do is add non-IP based rate limiting. So if you allow people to type in a onetime passcode that's sent to a channel that is tied to one of their communication channels that are tied to their account. So either through the email or through their phone number, you want to make sure that you're allowing people at least a couple of tries to get that right.
Kelley Robinson: We all fat finger one time codes occasionally, but if you only do rate limiting based on IP, you end up with a situation like the security researcher found from Instagram, which allowed you to bypass and brute force the account recovery process by guessing at the six digit codes that they were sending to their users. And so he was able to get around it by using multiple IP addresses. And I think the researcher said that they required about 5,000 IP addresses to hack into any Instagram account. And that might sound like a lot, but with a service like Google or Amazon, you can spin that up for about $150 to brute force access to any account and $150 for targeted account takeover is really not that much. People will gladly spend a lot more money than that trying to break into high value accounts, especially when the worth of those accounts is more than $150.
Kelley Robinson: Another anti-pattern with account recovery is just ignoring the second factor for account recovery. Hopefully this one is self-explanatory, but wow, was I upset I saw this. This is something that I tweeted earlier this year. When I went to reset my password on some account, for some reason, it hadn't saved in my password manager. And when I clicked on the link to reset my password, I got this notification that resetting my password would disable 2FA. This is incredibly disappointing for obvious reasons. I set up 2FA to protect this account only to realize that it's completely ignored when somebody tries to reset the password.
Kelley Robinson: And so if somebody were to get access to my Google account, I'm not going to name the site, but they were able to get it into this account as well, because they were ignoring my 2FA. And so, you should ideally treat account recovery as factor recovery. If somebody forgets their password, allow them to reset their password using an email, but still ask them to reset it with their 2FA. I, in this case, still had access to my 2FA, I just didn't have access to the correct password. And if they don't have either, then you can go through additional security measures to make sure that they are who they say they are, and that you're re-verifying their identity correctly.
Kelley Robinson: Something else that I want you to consider as you plan your account recovery flows is the power that you give to your help desk agents. If anybody is familiar with the social engineering village or things like that, where people are able to bypass a lot of parameters around security, because we're all human and once you get on the phone with someone, it's lot easier to convince them that you are who you say you are than convincing some automated system or automated recovery mechanism. So, can your agents disable 2FA? What controls do you have to allow them to do that? And I don't really care how you answer this question. I just want you to think about it. And that's true for so much of this stuff, right? There's going to be trade offs, there's going to be decisions that you have to make and I want you to be thinking about whether or not this is something that you're okay with your business allowing, or if this is something that you should add an extra control, add some additional friction, because it makes sense to secure your users.
Kelley Robinson: When you are designing these systems, think about what you should do and not just what you shouldn't. The National Institute of Standards and Technology or NIST has a very comprehensive digital identity guidebook that I encourage you to check out. And as you leave today and think about how you can improve your authentication systems, think about how to delight your most security conscious users and design your authentication system so the rest don't notice the friction.
Kelley Robinson: Understand why your users may not see the value of increased security measures. If you're going to push them on them, have a reason why. This was from a really interesting study on the usability of five different two factor authentication methods. One research participant, and a common sentiment from a lot of these participants was just like, "I don't think I have anything that people would want to take from me. So I think that's why haven't been very worried about it." And so when you have users like this, you either have to convince them that what they have is valuable or not create an unnecessary paranoia and fear in them because they might not believe that their own accounts are that valuable. If they don't care, then maybe you don't have to add this additional friction to secure them in those ways. And it's because of this that I encourage you to be intentional, consider your business and optimize the friction that you add accordingly.
Kelley Robinson: I hope that I've given you some inspiration for how to think about your authentication systems. I hope I've given you some ideas of the things that you might not want to do. Please reach out to me on Twitter if you have any questions. Once again, my name is Kelley Robinson and thank you for listening
From unpastable password fields to clunky 2FA setup, your site's user experience is an opportunity to delight (or frustrate) your customers. There are a lot of design choices from onboarding to account recovery; this talk will look at best practices for implementing seamless user onboarding UX, operating multiple 2FA channels at scale, and supporting your customers through it all.
You'll leave the session with a framework to determine the right level of authentication friction, incentivize user opt-in to 2FA, and decrease support tickets. Finally, we'll discuss how and why to delight your most security-conscious customers while catering to the common denominator.