WEBVTT 00:14.200 --> 00:17.740 Good morning, and welcome to the AppSec Village. 00:17.740 --> 00:20.860 I hope you were here for our first keynote speaker. 00:20.860 --> 00:25.380 Welcome to day one of AppSec Village, part of DEF CON 2020. 00:25.540 --> 00:32.300 I really wish we were all together in one big room like we were last year, but that's just not going to happen this year. 00:32.300 --> 00:35.680 So, in the meantime, thanks for tuning in. 00:35.680 --> 00:38.560 Thanks for watching along with us. 00:39.420 --> 00:43.620 I want to take the moment to introduce you to our next speaker. 00:43.640 --> 00:49.700 Our next presentation is going to be 2FA in 2020 and beyond by Kelly Robinson. 00:49.700 --> 00:52.460 Kelly works on the account security team at Twilio. 00:52.460 --> 00:57.480 Previously, she worked in a variety of API platforms and data engineering roles at startups. 00:57.480 --> 01:05.160 Her research focuses on authentication user experience and design tradeoffs for different risk profiles and 2FA channels. 01:05.160 --> 01:07.480 We all know how important 2FA is today. 01:07.480 --> 01:09.680 We all want to protect our accounts. 01:09.760 --> 01:11.300 And I'm looking forward to this talk. 01:11.300 --> 01:12.160 I hope you are too. 01:12.160 --> 01:17.100 So, please give a warm AppSec Village welcome to Kelly Robinson. 01:18.360 --> 01:20.100 Hey, everyone. 01:20.380 --> 01:30.360 I am coming to you today from Bravel, wherever you may be on this March 152nd. 01:30.740 --> 01:35.140 Hopefully, your day is going better than the person who has this password. 01:35.380 --> 01:52.940 But even though I trust everyone tuning into a DEF CON talk to have better password hygiene than something as simple as 1, 2, 3, 4, 5, 6, the fact is there's still a lot of folks out there with short, guessable passwords or people that are reusing passwords across multiple sites. 01:54.380 --> 02:04.200 And as much as we'd like to believe that we're better than this, the website haveibeenowned.com proves that simple passwords like 1, 2, 3, 4, 5, 6 are still incredibly common. 02:04.200 --> 02:08.880 This password has been seen almost 24 million times across data breaches. 02:09.200 --> 02:13.300 And attackers can use this to do credential-stuffing attacks across the web. 02:13.300 --> 02:24.260 And it can basically allow them to hack into a lot of accounts and compromise a lot of credentials and ultimately make a lot of money off of unsuspecting individuals. 02:24.340 --> 02:39.140 And that's what we're here to discuss today, this reality where we are so owned that passwords are no longer enough, how other factors, second factors, in fact, can help us stay more secure, and how to evaluate the different options out there. 02:39.920 --> 02:42.160 So my name is Kelly Robinson. 02:42.160 --> 02:45.480 I have been working at Twilio for about three years. 02:45.560 --> 02:58.760 And I specifically work on Twilio's account security team, working with our products for things like Verify, Lookup, anything that has to do with phone verification, two-factor authentication, phone and email intelligence, things like that. 02:58.760 --> 03:00.380 And this team has evolved a lot. 03:00.380 --> 03:04.780 We acquired Authy about five years ago, and that was kind of the genesis of the team. 03:05.700 --> 03:11.760 So Authy is our free consumer application that was recently rendered to include the Twilio name about five years later. 03:11.760 --> 03:17.140 But we also have APIs for adding things like two-factor authentication into your applications. 03:17.140 --> 03:23.620 And I spend a good chunk of my time educating developers about security, especially when it comes to authentication itself. 03:23.660 --> 03:34.640 And so this talk is going to incorporate a lot of the things that I've learned in the last few years working with developers on a variety of challenges and our customers on their authentication challenges as well. 03:36.120 --> 03:42.020 And the failure of good authentication often results in what we call account takeover, or ATO. 03:42.020 --> 03:44.220 And this is why this is such a big problem, right? 03:44.220 --> 03:49.740 Like, if there wasn't anything of value on the other side of an account, we wouldn't be as concerned about this. 03:49.740 --> 03:56.360 But this is a $7 billion problem, so the industry is really incentivized to find a solution here. 03:56.360 --> 04:10.960 And from the 2020 Javelin Strategy and Research Study that just came out a few months ago, one of the things that they noted is that account takeover fraud is one of the hardest types of fraud to identify because there's so many channels, multi-channel account access, 04:10.960 --> 04:14.580 and the desire to reduce friction in the consumer experience. 04:14.600 --> 04:22.420 And so we're trying to make it easy for people to log in, but we also want to keep out the people that shouldn't have access to those accounts. 04:22.420 --> 04:25.180 And those can sometimes be conflicting goals. 04:25.180 --> 04:28.680 So how do we accomplish this, and how do we accomplish those goals? 04:29.720 --> 04:34.500 So protecting our accounts, we have these three types of factors that we'll talk about. 04:34.520 --> 04:41.920 You need to use a factor of authentication, and using any two of these means that you're using two-factor authentication. 04:42.080 --> 04:44.000 So there are three types of factors that we talk about. 04:44.000 --> 04:46.540 Something that you know, this could be like a password. 04:46.600 --> 04:49.820 Something that you have, this could be a key or a phone. 04:49.820 --> 04:56.620 And then something that you are, so this is something biometrics, like a fingerprint or a face ID or something like that. 04:56.740 --> 05:02.660 And all of the factors that we're going to be talking about today are channels that fall into this possession category. 05:03.200 --> 05:15.740 And I just kind of wanted to go over what the different pros and cons of a lot of these different common channels for two-factor authentication are, so we can think about why we would or would not enable some of these types of channels. 05:15.740 --> 05:21.040 And starting with second-factor authentication, using SMS 2FA codes. 05:21.040 --> 05:27.740 And so one of the big reasons that people still like SMS-based 2FA is that onboarding is so easy. 05:27.740 --> 05:32.820 So about 99% of Americans have a phone capable of receiving text messages. 05:33.200 --> 05:36.120 And that makes a big difference, right? 05:36.120 --> 05:45.620 Like if you can't get people to turn on 2FA or opt into 2FA, then you're not going to have any of the benefits of having the second factor offered to them. 05:45.620 --> 05:56.900 And because of this easy onboarding, because it's a familiar experience now, this is something that a lot of companies still like to offer, because it's offering that additional security without that additional friction. 05:57.160 --> 06:02.380 Unfortunately, as a lot of people know, SMS-based 2FA is not that secure. 06:02.380 --> 06:07.700 So one of the main reasons that we say this is because of something called SIM swapping. 06:07.700 --> 06:14.280 So this is where an attacker could use either social engineering or bribery to get my SIM card sent to you. 06:14.280 --> 06:18.660 And then you could basically take over control of my phone number. 06:18.660 --> 06:23.680 And so it's not device control, so SIM swapping allows you to take control of a phone number. 06:24.020 --> 06:30.560 And that can give you a lot of access to things that are being sent to me, like two-factor authentication codes. 06:31.960 --> 06:36.700 So SMS one-time passwords are really convenient, but they are an insecure channel. 06:37.460 --> 06:42.080 The next thing that I wanted to talk about was TOTP, or time-based one-time passwords. 06:42.080 --> 06:45.140 And this is a way to generate tokens based on an algorithm. 06:45.140 --> 06:48.660 So the inputs here are a secret key and your system time. 06:48.660 --> 06:52.580 And those get put through a one-way function that pops out the truncated token. 06:53.120 --> 06:56.940 So this is what Google Authenticator, Authy, apps like that use. 06:56.940 --> 06:58.800 It's an open standard. 06:59.120 --> 07:03.340 And symmetric key cryptography offers increased security compared to SMS. 07:03.480 --> 07:07.820 But if somebody gets access to that shared secret, then the method is easy to compromise. 07:07.820 --> 07:10.540 And you might be saying, well, don't leak that secret. 07:10.560 --> 07:14.900 But one of the ways that we'd share that secret is by scanning a QR code. 07:14.900 --> 07:17.400 There's ways that that QR code can get leaked. 07:17.400 --> 07:27.140 At a previous job, we used to keep a copy of a QR code for TOTP in the shared one-password file that we used for engineering onboarding. 07:27.140 --> 07:31.560 Because we wanted to enable 2FA, but we needed multiple people to have access to it. 07:31.560 --> 07:35.980 So that's one example of how a TOTP secret could get leaked. 07:36.240 --> 07:38.760 It offers also some distinct advantages. 07:38.760 --> 07:41.480 Like I mentioned, it's an open standard, which is pretty cool. 07:41.480 --> 07:44.800 So you can use the app of your choice to do this. 07:44.800 --> 07:50.240 And also, because the inputs are offline inputs, this method is also available offline. 07:50.240 --> 08:01.660 So not that anybody's doing a ton of traveling right now, but this is really useful for people when they're on a plane or in a foreign country where they might not have good cell service or cell service of any kind. 08:01.840 --> 08:04.580 But unfortunately, this does require an app download. 08:04.860 --> 08:11.820 And so this is something that you want to keep in mind, because that's going to add additional friction to get people to sign up for this method. 08:11.820 --> 08:14.880 And then I do want to mention the expiration user experience. 08:14.880 --> 08:26.920 Because in a study on the usability of different factors, researchers found that two-thirds of participants using TOTP via Google Authenticator had problems entering the six-digit code before it timed out. 08:26.920 --> 08:30.900 And so that could be a problem, depending on the types of users that might be using this. 08:30.900 --> 08:35.580 That expiration logic helps keep it secure, but it also could make it harder to use. 08:36.340 --> 08:38.220 Overall, this is a pretty good option. 08:38.220 --> 08:43.620 We see a lot of security-conscious companies adding TOTP as a 2FA option. 08:43.620 --> 08:53.300 And it's a really good next step of a way to add an open-source, open-standard option on top of SMSVite 2FA if you want to add additional security. 08:54.780 --> 08:58.040 So I also wanted to talk about pre-generated codes. 08:58.040 --> 09:02.240 And so these are something called, you know, like we might know these as backup codes. 09:02.240 --> 09:05.360 You don't see these used a lot for ongoing login. 09:05.860 --> 09:11.080 But I wanted to mention these because a study that I'm going to reference talks about using pre-generated codes. 09:11.080 --> 09:13.160 And then the benefit is that these are really easy to use. 09:13.160 --> 09:17.800 These are basically like passcodes or passwords that are generated for you. 09:17.820 --> 09:19.940 So they're less likely to be reused. 09:20.280 --> 09:22.800 They're more likely to be more secure. 09:23.060 --> 09:26.160 They're not going to be 1, 2, 3, 4, 5, 6. 09:26.160 --> 09:32.860 But, you know, because of that, 25% of participants in the study noted that these pre-generated codes didn't really feel secure, though. 09:32.860 --> 09:35.080 Because they're just kind of written down on a piece of paper. 09:35.080 --> 09:45.720 And the other problem with this is if you've ever been somebody that has been asked to store backup codes or implemented a system that has this kind of system, like, how do you store those? 09:45.720 --> 09:49.220 A lot of companies don't give you real guidance on that. 09:49.640 --> 09:52.540 And this is something that might not just, like, feel that secure. 09:52.620 --> 09:55.700 So this is something that I think is an option for backups. 09:55.700 --> 09:59.380 But the ongoing usability of it might not be super practical. 10:00.760 --> 10:02.980 Finally, I want to talk about push authentication. 10:02.980 --> 10:06.660 And this was really popularized by apps like Dual Authenticator. 10:06.660 --> 10:09.540 And users love this because it's so low friction. 10:09.540 --> 10:13.460 So you can approve or deny a login request directly from your smartwatch. 10:13.500 --> 10:17.400 And it uses asymmetric key cryptography, which means that you have two keys. 10:17.400 --> 10:21.100 The private key is only ever going to be stored on your device. 10:21.100 --> 10:29.740 And so that really keeps you more secure and prevents you from leaking a shared secret like you might be able to with TOTP. 10:29.740 --> 10:34.900 And this is the only form of 2FA that adds the option to explicitly deny a login. 10:35.120 --> 10:40.700 But unfortunately, it's so low friction that you could easily approve an authorization request just to get rid of it. 10:40.900 --> 10:50.500 And so if somebody is attempting to attack your accounts in the middle of the night, you might be able to unintentionally approve a request just to make it go away. 10:50.800 --> 10:52.800 And this also is a proprietary solution. 10:52.800 --> 10:55.080 So it's going to require a special app. 10:55.080 --> 10:56.740 So you could do this with something like Authy. 10:56.740 --> 10:58.180 You could do this with something like Duo. 10:58.180 --> 11:01.080 And you could also bake this into your own application. 11:01.360 --> 11:06.940 But like with TOTP, getting users to download another app is always going to be a challenge. 11:07.160 --> 11:18.120 I think the way that we'll see this become more common is with companies that have a lot of mobile users that already have their apps, baking this into the existing apps that are already on their phone. 11:18.120 --> 11:20.580 So you've seen this with something like Google Prompt. 11:20.580 --> 11:35.700 If you enable Google Prompt and try to log in on the browser, what Google will do is say, hey, check your phone, open up any Google app on your phone, and it will pop up this type of, is this you trying to log in message without requiring that the user downloads an additional app. 11:35.700 --> 11:43.780 And so that is one of the ways that you can kind of get around that user experience hurdle of having users opt into a more secure solution. 11:44.380 --> 11:45.300 This seems great. 11:45.300 --> 11:47.140 It's really cryptographically secure. 11:47.140 --> 11:56.180 But I think the onboarding logic is going to be something that we're going to struggle with for the next few years until this becomes more common. 11:56.400 --> 11:59.120 And there's always this problem that it might be too convenient. 12:00.120 --> 12:02.400 And then lastly, we'll talk about WebAuthn. 12:02.400 --> 12:04.380 And this is the new hotness for good reason. 12:04.380 --> 12:09.780 It offers a really high level of security with asymmetric key cryptography like push authentication. 12:10.120 --> 12:13.020 So the private key is only ever going to be stored on the device. 12:13.020 --> 12:16.180 But it's also an open standard like TOTP. 12:16.220 --> 12:22.660 So the biggest drawbacks with WebAuthn right now is that it's still relatively new and setup can be a little bit clunky. 12:22.660 --> 12:28.320 Some of the new devices are starting to bake this into the actual device itself. 12:28.420 --> 12:33.900 And so Android phones can now be used as a WebAuthn authenticator for Google products. 12:33.900 --> 12:37.700 But this is not something that you're seeing as widespread yet. 12:37.700 --> 12:42.200 Hopefully this will be something that will be rolling out more widespread with devices that we already have. 12:42.200 --> 12:51.320 But for something kind of third party that you can use to do this like a YubiKey, you need that additional authenticator right now to do this in a lot of places. 12:52.220 --> 12:55.040 An authenticator that's compatible with the standard. 12:55.040 --> 12:58.440 And , you know, YubiKeys, Titan keys, they're not exactly cheap. 12:58.440 --> 13:03.380 And you can't also reasonably expect that every user of your application will have one. 13:03.380 --> 13:11.520 So until something like this becomes a standard available on every mobile phone, it's going to be harder to implement this across the board. 13:12.100 --> 13:22.380 So like I said, as more devices like we already have, like our phones and our laptops, start to adopt the standard and become those kind of compatible authenticators, we will see an uptake in this factor. 13:22.380 --> 13:26.020 And I think this is where you can kind of set your sights where things will be going. 13:26.680 --> 13:29.600 But it is more currently more popular with companies. 13:29.600 --> 13:32.700 So like your IT department can get you the YubiKey right now. 13:32.700 --> 13:34.680 It can hand you the physical token. 13:34.980 --> 13:37.500 So that's something where you might also be seeing this. 13:37.500 --> 13:42.800 But a lot of these factors we're kind of focusing on as a consumer application channel. 13:44.280 --> 13:49.580 But I did want to back up these kind of qualitative examples with some more quantitative data. 13:49.580 --> 13:53.980 And to do that, I wanted to think about more granularly how we're measuring the effectiveness of 2FA. 13:53.980 --> 13:59.300 And so separating this into three categories, kind of thinking about this in the life cycle of 2FA. 13:59.300 --> 14:03.300 So there is this onboarding consideration, right, that I've mentioned a couple of times already. 14:03.300 --> 14:11.800 There's also a user experience, ongoing user experience for how you're going to work with these different channels as you're using them on an ongoing basis. 14:11.800 --> 14:17.320 And then also the account recovery side of things, like what happens when you lose one of these factors? 14:17.320 --> 14:18.840 What do you do at that point? 14:18.840 --> 14:21.340 Is there a path to recovery there? 14:22.580 --> 14:25.720 And so the research that I'm talking about is from Brigham Young University. 14:25.720 --> 14:28.480 It was presented at the Supes conference last August. 14:28.800 --> 14:31.800 And so it was a study focused on setting up five factors. 14:31.800 --> 14:41.500 And so the factors that they talked about are the ones that we kind of already walked through, which were SMS, TOTP, pre-generated codes, push authentication, and U2F security keys. 14:41.500 --> 14:50.020 So a couple of important caveats is the study didn't take into account how to store pre-generated codes. 14:50.360 --> 14:55.120 And so that's something that I think is pretty important for this type of channel. 14:55.220 --> 14:59.640 But 25% of participants noted that the pre-generated codes just didn't feel secure. 14:59.640 --> 15:03.120 But when it comes to factor setup, this is the winner from the study. 15:03.540 --> 15:07.540 But like I said, the code storage wasn't considered for timing. 15:07.540 --> 15:11.460 So I don't know exactly what that would be like on an ongoing basis. 15:11.880 --> 15:21.360 From a different study in 2018 that focused just on Yubikeys, I think this study is really interesting because the success varied a lot depending on the platform that they were setting it up on. 15:21.360 --> 15:27.060 Even though the channel, the thing that they were using to set up the U2F was always a Yubikey. 15:27.060 --> 15:30.900 It was always the same Yubikey that they were using across channels. 15:30.900 --> 15:37.320 So 83% of people were successful on Google, where only 32% of people were successful on Facebook. 15:37.320 --> 15:41.940 And if you've been following U2F and WebAuthn, you know a lot has changed since 2018. 15:42.040 --> 15:48.360 But I do think this is a really interesting look at how onboarding user experience impacts user success. 15:48.360 --> 15:52.160 And so you can guide people towards a successful solution here. 15:52.300 --> 16:06.540 But you don't want to guide people in a way like Microsoft Authenticator or Windows Logon Authorization Tool did, where more people locked themselves out of their computer than were able to successfully set it up for that particular platform. 16:07.560 --> 16:13.200 So moving on to usability, one measure of usability was the amount of time that it took to authenticate. 16:13.200 --> 16:17.080 And in that metric, U2F and Push were the winners there. 16:17.080 --> 16:19.960 So they have the fastest median authentication times. 16:19.960 --> 16:31.220 So compared to SMS, some Duo research from last year said that this can save people 13 to 18 minutes annually in terms of ongoing authentications, if time is something that you're concerned about. 16:31.220 --> 16:33.620 And this is a measure of usability ongoing. 16:33.620 --> 16:41.600 But the system usability scale, or SUS, this is something that's a standard measurement used by researchers for this type of thing. 16:41.720 --> 16:47.200 So actually all of the methods had a pretty good usability score, but TOTP came out on top. 16:47.200 --> 16:49.940 Again, this is like ignoring just passwords. 16:49.940 --> 16:57.520 So turns out people don't like adding a second factor to a lot of their authentication, because that's additional friction. 16:57.520 --> 17:02.440 But if you're going to be using a second factor, then TOTP was what they considered most usable. 17:02.440 --> 17:12.320 And this actually surprised me, because this was the same study that said that two-thirds of users had issues with the timeout, but that didn't affect their rating here, so maybe that's something that we don't need to be as concerned about. 17:13.240 --> 17:27.420 I do want to point out that there was somewhat of an inverse relationship here, because U2F and Push had some of the lower usability scores, so the researchers observed that faster authentication does not necessarily mean higher usability. 17:28.560 --> 17:33.740 So this is something that we were looking at, and you might notice that SMS does not come out on top on any of these. 17:33.740 --> 17:35.540 People didn't really like it as a factor. 17:35.540 --> 17:39.200 It was one of the lower factors for the authentication score. 17:39.200 --> 17:49.000 But I do think that even though there's a lot of tradeoffs to the level of security in these options, it's important to note that SMS-based 2FA is still better than no 2FA at all. 17:49.000 --> 17:55.500 And this is really easy for me to say, like, you know, I work for a company that does this, but there's research here to back me up. 17:55.500 --> 18:09.280 So a 2019 Google study found 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. 18:09.280 --> 18:18.320 So it's still really good coverage, especially for something that's really easy to set up that might have high likelihood that users are actually going to turn on a second factor. 18:18.760 --> 18:23.540 But when you start looking at push authentication, there is increased protection. 18:23.540 --> 18:32.560 So this gets bulk phishing attack protection up to 99%, and it has a 90% effectiveness for targeted attacks as well. 18:32.560 --> 18:38.920 So you have different options for 2FA, but you also do need to get your users to enable the extra security. 18:39.440 --> 18:41.580 And adoption of 2FA is pretty abysmal. 18:41.580 --> 18:43.800 There's a few reasons for that. 18:44.400 --> 18:47.520 This is especially abysmal for opt-in 2FA. 18:47.520 --> 19:05.880 Last month, DHH on Twitter, who works for Basecamp, I think, and is behind the new email platform, Hey, was asking about how the opt-in rate for different companies was for consumer 2FA. 19:06.160 --> 19:10.700 And companies willing to share this data say that it's usually somewhere between 1% and 2%. 19:10.700 --> 19:21.580 Depending on the type of platform, depending on how you're getting users to turn it on, you probably are going to have a pretty low rate of adoption here. 19:21.580 --> 19:24.760 So he mentions that Basecamp was at a paltry 1%. 19:25.920 --> 19:31.380 And one of the observations behind this is that there is technology like this. 19:31.380 --> 19:38.580 Technology is available to help mitigate the risk and improve the consumer experience, but it often goes unused. 19:38.580 --> 19:55.180 And so I think this is one of the things that we as security professionals and people that have the ability to encourage people to opt into these more secure measures, need to be considering how we can push people in that direction without increasing too much paranoia. 19:55.800 --> 20:05.780 So in terms of 2FA adoption, a 2019 BYU study found that people were willing to add 2FA to their accounts if they saw the value in the account. 20:05.780 --> 20:11.000 But 13% of participants just thought that the inconvenience was too high, no matter what. 20:11.460 --> 20:14.780 And that's because a lot of people just believe they're not a target. 20:14.920 --> 20:19.700 And so this research participant said, I just don't think I have anything that people would want to take from me. 20:19.700 --> 20:22.620 So I think that's why I haven't been very worried about it. 20:22.620 --> 20:24.860 And you can see this with a lot of people in your own life. 20:24.860 --> 20:28.460 They don't understand the risk that's associated with all of their accounts. 20:28.540 --> 20:29.740 And maybe that's okay. 20:29.740 --> 20:35.140 Maybe you don't need to be adding two-factor authentication to the pizza delivery app that you're using. 20:35.140 --> 20:48.420 But how do we encourage people to add stronger authentication methods beyond passwords to things like their emails and like their bank accounts and other places where that level of paranoia is perhaps justified? 20:49.240 --> 20:51.160 So hope is not lost here. 20:51.160 --> 20:54.420 Awareness and adoption have almost doubled in the last two years. 20:54.420 --> 20:55.620 There's reasons for this. 20:55.620 --> 20:58.500 Bitcoin has spiked a couple of times within there. 20:58.500 --> 21:02.080 But there's other things that we might be able to attribute this to. 21:02.080 --> 21:06.500 And so one of these is how we drive adoption of multi-factor authentication. 21:06.500 --> 21:11.440 And websites are getting more savvy about how they're getting people to turn on 2FA. 21:11.720 --> 21:17.720 But unless you're somebody like Coinbase, you're probably not going to make two-factor authentication mandatory. 21:17.980 --> 21:24.040 But you do have other options than just hiding it in profile settings where people aren't going to think to go get it. 21:24.040 --> 21:26.540 And so you can prompt people when they log in. 21:26.540 --> 21:28.480 You can offer product incentives. 21:28.480 --> 21:36.780 You can have a really annoying and persistent login prompt that is telling people they need to turn on additional factors for authentication every time they log in. 21:36.780 --> 21:42.040 The more annoying you are about it, the more likely that people are going to be to turn it on. 21:42.040 --> 21:46.460 But that's also going to increase the friction and you don't want to annoy your customers too much. 21:46.900 --> 21:53.500 So we do know that strategies like product incentives work from looking at the Google Trends for 2FA searches. 21:53.500 --> 22:00.980 So if you can guess what the spike in August 2018 was, it's only gone up from there. 22:00.980 --> 22:04.820 But it was pretty flat for many, many years leading up to that. 22:04.820 --> 22:11.600 That was when Fortnite decided to offer in-game incentives for its users to turn on two-factor authentication. 22:11.640 --> 22:16.340 And so if you're not familiar with Fortnite, it's an incredibly popular video game. 22:16.360 --> 22:21.880 And video games are some of the people that have gotten most creative with the incentives that they're offering people. 22:21.880 --> 22:27.960 One, because there's in-game trading that has real monetary consequences to their users. 22:27.960 --> 22:32.560 But two, because some of the incentives that they can offer don't actually cost them a lot of money. 22:33.460 --> 22:39.440 And so now even two years later, three of the top five related search queries to 2FA have to do with Fortnite. 22:39.440 --> 22:44.020 Three of the top five related topics to 2FA have to do with video games. 22:44.020 --> 22:46.520 Epic Games is the company that owns Fortnite. 22:46.640 --> 22:49.800 But they aren't the only ones that are offering incentives. 22:49.800 --> 22:53.260 Lots of gaming companies are offering incentives around that. 22:53.260 --> 22:55.120 You can see lots of examples there. 22:55.120 --> 22:58.240 But there's other companies that are offering product incentives as well. 22:58.240 --> 23:05.240 So a good example of this is MailChimp will offer you a 10% discount for three months for users that turn on 2FA. 23:05.620 --> 23:11.800 And so you can understand kind of the trade-off here of what it would be valuable to your company. 23:11.800 --> 23:13.840 Like, what is the account takeover risk? 23:13.840 --> 23:17.100 What is the loss that you're experiencing from something like this? 23:17.100 --> 23:25.460 And does it make sense for you to offer some product incentives or discounts to your customers that might get them to opt into additional security? 23:27.320 --> 23:32.580 And so like anything, you want to make sure that you're going to measure how effective this was. 23:33.020 --> 23:37.080 So ideally you would be setting these measures before you embark on this kind of journey. 23:37.080 --> 23:48.700 But some of the things that I encourage people to think about as they're measuring the effectiveness of their authentication strategies, like this is going to depend on your business, but here are some of the options that you might have. 23:48.700 --> 23:51.200 Just total losses due to account takeover. 23:51.200 --> 23:53.740 You probably want to see that number go down. 23:53.940 --> 23:58.020 You might want to care about the total number of compromised accounts too. 23:58.560 --> 24:02.740 Decreasing the number of customers that are actually having their accounts taken over. 24:02.960 --> 24:08.700 One thing that I do think is really important to look at is just the support costs related to the losses. 24:08.800 --> 24:17.980 So if you're somebody that's starting to require or encourage a lot more two-factor authentication, there are going to be additional support hurdles that you're going to come across. 24:17.980 --> 24:23.860 So especially when it comes to the account recovery side of things, people are going to get locked out of their accounts more often. 24:23.860 --> 24:25.980 And you want to have a smooth path. 24:26.200 --> 24:27.620 Hopefully self-service. 24:27.620 --> 24:35.900 Hopefully you've enabled three or four factors so that they can gain access to their accounts again if they lose access to any one of their factors. 24:35.900 --> 24:45.200 But you want to make sure that you've also equipped support with the tools to make sure that they can securely and safely get people back into their accounts. 24:45.500 --> 24:50.700 Even if this is going to take more time on the support team, it might be worth it overall. 24:50.700 --> 24:55.740 And finally, you just want to make sure that user satisfaction is at least staying the same if not going up. 24:55.740 --> 25:06.380 If you're doing something like having really persistent login prompts for turning on 2FA, you might want to make sure that you're not annoying your customers too much overall. 25:07.480 --> 25:10.900 So there's definitely no one-size-fits-all solution here. 25:10.900 --> 25:17.440 But the advice that I end up giving a lot of folks boils down to something like this, which is to delight your most security-conscious users. 25:17.440 --> 25:28.000 You don't want people that are paranoid with good reason, have higher security needs and concerns, to be upset at the lack of options that you're providing. 25:28.000 --> 25:30.300 But you do want to provide options for the rest. 25:30.300 --> 25:38.320 You don't necessarily need to force everybody on your consumer website to have TOTP or YubiKey or anything like that. 25:38.320 --> 25:44.740 But you want to make sure that it's usable for people, depending on the risk that they're willing to accept. 25:45.240 --> 25:53.800 Because, like the security researcher Cormac Hurley says, when we exaggerate all dangers, we simply train users to ignore us. 25:53.820 --> 25:58.760 So I hope I've given you some inspiration for how to think about your authentication systems. 25:58.760 --> 26:00.220 I'll be around. 26:00.220 --> 26:04.360 You can find me on Discord, you can find me on Twitter if you have any questions. 26:04.360 --> 26:08.700 Once again, my name is Kelly Robinson, and thank you for listening.