 Welcome back, everyone. Sorry for the glitches there for a moment. So we are back for our last talk of the day, and I have just ceremonially cracked open one of the many NorthSec beers. This is the last one that remained in my apartment. So I'm very excited to welcome this next speaker. She spoke last year at NorthSec and was a really well-received talk. And the talk is going to be designing customer account recovery in a 2FA world by Kelly Robinson. Kelly works on the account security team at Twilio. Previously, she worked in a variety of API, platform, and data engineering roles at startups. Her research focuses on authentication user experience and design trade-offs for different risk profiles and 2FA channels. Kelly lives in Brooklyn, is an avid home cook, and spends way too much time on Twitter. I'm sorry, I editorialized with the way too much time. Apologies, it was just too much time. She tweets at Kelly Robinson. Yeah, please give her a virtual hand of applause. Welcome, Kelly, excited for this. Cheers. Thank you. Disappointed that I do not have one of those beers as well, but I will be ceremoniously cracking one up after I give this talk. So thank you everyone for joining us today. Thank you for sticking around for the end of the day and for this talk. I can tell you the exact moment that I was inspired to give this talk. Like a lot of things in security, user experience is one of the most important parts, and getting that balance right between usability and necessary friction is always something that we're going to have to keep in mind. And so when I tried to reset my password for this website, and they told me that resetting the password would just deactivate my 2Factor authentication, I was a little upset. But I think that this whole balance of usability and friction is especially true with authentication because it's one of the most common security measures that everybody deals with. And we deal with it on a repeated basis. We're logging into websites repeatedly day after day into multiple websites every single day. And so this is something that everybody kind of around the world is dealing with and is familiar with. And so we as security professionals have to be designing these systems in a way that makes sense. So no one expected to be quarantined for a good chunk of 2020, but I think one of the outcomes of this is that we're all doing a lot more business online, and that makes it increasingly important to shore up our online authentication and think about how we're allowing customers to regain access to their accounts. So I'm gonna be sharing some of the things that I think are good options for designing account recovery when users have 2FA enabled. I'm specifically calling out customer account recovery here because I think there's a different way of thinking about this problem for user facing applications compared to something like internal employee account recovery. So I'm gonna focus on consumer applications and end user security. So my name is Kelly Robinson. I have been working at Twilio for about three years. I specifically support Twilio's account security products for things like user verification and phone intelligence. This team has been evolving a lot since it was acquired. So the Opi team was acquired by Twilio about five years ago. Opi is our free consumer application for 2FA that you may be a user of. And this talk is going to incorporate both a lot of the things that I've learned from working on security products for the last few years, working with our developers and our customers on their authentication challenges, but also some of the things that we've learned from running a two-factor authentication product and a product that has an account recovery option, a product that has a lot of security considerations that we have to make around recovery and how that affects our customers that are using it. If you're watching this in a logged in Twitch account, Twitch is an Opi customer. So if you set up 2FA with Twitch that you're going to be using Opi for that. And I can tell you that when Twitch users need to reset their two-factor authentication, they're dealing with our support team and our support team are very, very lovely people. And we have to make a lot of considerations around how to make sure that people can get back into their Twitch accounts without having those accounts taken over. So of course we hope that users don't lock themselves out of their accounts, but there's a lot of common reasons that we have to take into account when we're designing these systems and we're designing account recovery. People forget passwords, that's a common one. They change their phone numbers, that's also common, especially in cases where two-factor authentication involves a phone number, which a lot of cases do. People lose devices, that could be an authenticator application or a physical hardware security key or they upgrade to the latest iPhone. Maybe they don't lose something, but they're getting a new device and they forget that there was anything important on that old device. But we have to figure out how to address these issues while still guarding against attackers and guarding against account takeover attempts. And addressing this is expensive. This can cost companies up to $70 per support call to unlock an account. So we have to be thinking about how we can minimize this cost while still protecting user accounts. So one thing I wanted to look at was the different factors that we have access to and how we can evaluate using these factors for account recovery. And one thing to note is that the more of you these that you collect from the user first signs up, the more that you'll have to trust and verify against when they attempt an account recovery. So generally, and I'll be walking through more concrete recommendations towards the end of the talk, but generally, even if you're having a user log in with two factors, you probably want to be collecting at least three factors at some point during an authenticated session so that they can make sure that they can log in with at least two factors if they lose one of the ones that they were using. So let's start with looking at them and the knowledge factors or things that you wouldn't know. And these could be passwords, security questions or specific account information. And these could be things like recent transactions or hopefully other secret details about the account. Knowledge factors are great because they're easy to use and to set up and they can't exactly be lost. The reason security questions became so popular as a recovery mechanism is because things like your mother's maiden name or the name of your first pet, those aren't things that are going to change and you'll likely remember those details. However, knowledge factors like passwords can of course be breached and many security questions or account details could be searched. It's not impossible to find the street that someone grew up on or guess the color of their first car. And so humans are of course forgetful. So anything like a password could also be lost that way. Looking at inheritance factors are things that you are like your fingerprints, your voice or even the way that you type or another way to identify you. The benefits of these is that you can't lose or forget these but the downside is that you can't really change these. So the risk is really high for these getting breached which makes implementation of inheritance factors delicate I would say. And it's a big reason that these aren't widely supported. So if you saw the fingerprint cloning talk from earlier you also know that these can be cloned which is very scary. But moving on to possession factors these are something that you have and these tend to be more secure than passwords because they can be harder to fish and don't get leaked in data breaches. So these could be things that you have like your phone, backup or recovery codes and hardware security tokens like Ubiquiz. Of course when it comes to something you have people are people, we're all human and we tend to lose and replace things. And that means it's hard to guarantee that these will be available for account recovery. And so possession also introduces additional friction when you try to set something up and that could be additional friction especially compared to something that you know or something that you are if it requires that you have access to a physical object then it's going to be a little bit of additional friction during that setup phase and that's something that you're probably also going to want to keep in mind. I specifically wanted to highlight one type of possession factor that we see a lot for account recovery and that's backup or recovery codes. And so these are given to you. So they're a little bit more likely to be longer and less likely to be reused. And so in that sense, they're a secret string that is a little bit more secure than a password but that means that people have to store backup codes somewhere and while some sites will give you specific options, some sites will tell you write them down, print them out and store them in a safe place, save them in your password manager, email them to yourself. I think that's a reasonable option. This is a screenshot from Instagram when you set up two factor authentication and they give you your backup codes. These backup codes are fake but the messaging here is real and they don't really give you any useful guidance. They just say make sure you keep them in a safe place and so what am I supposed to do with that? And while I haven't found any research on this and please if anybody has any research on how many people actually have access to backup codes when they need them, please share that with me but my hunch, my hypothesis here is that most people don't actually save these and so these become a somewhat useless form of recovery. And so like what is the solution here? There's a debatable solution here that you could email the recovery codes to the user. That's like automatically do that not tell the user to store them themselves but actually email them to them. Of course if they lose access to their email then they're locked out or if somebody gets into their email then all of a sudden it's not really 2FA anymore. They're also screwed if that's the case but it could be a better solution for some people and is that any better or worse than those of us who store our backup codes in our password manager? We're kind of all concentrating risk in one area. So I just have a lot of opinions about backup codes and so this is something that I kind of wanted to call out specifically as a recovery option. You know I'm not really saying that you should start automatically emailing users your backup codes but it might have a higher usability than whatever most people are doing today. So let's spend a little bit of time looking at a few companies and their account recovery processes. A lot of companies can be intentionally vague about this but some have really good documentation about their processes and some of these are companies that I've personally dealt with. So let's start with a pretty questionable example. So this is a financial services company that you may or may not know, I'm not gonna name them. They use a pretty interesting form of 2FA. It's a proprietary form of 2FA so I can't use you know, Authy or another authenticator app that allows backup. They just as a weird aside that doesn't really have anything to do with account recovery. They have you append the 2FA code at the end of your password, which is a little weird. But the thing that annoys me about this company is that so when you get a new phone there's not an automated process for transferring your 2FA to that new phone. You have to call the help desk of this company. As a millennial of course I hate calling anyone but it's not just that. When you call the company to reset your 2FA, what you have to do is authenticate yourself over the phone and like they don't really do any actual authentication. All they require is your username and your phone number in order to change this on your account. And so that's a little bit frustrating. It's kind of the worst of both worlds. It's not self-service online. So they're not like foregoing extra security for usability. They're making it a little bit harder to reset this process but it's also not even that secure. And since account recovery over the phone is so common make sure your company is securing your contact center with the same rigor that you secure your website. This is what I spoke about last year at NorthSec but I still think this is really important. So here's a blog post that I wrote this week about how to do call center security well. So you can find that on the Tbilio blog. Next let's look at Authy. So we're one of those companies that we don't outline in our public documentation everything that we do for account recovery but we basically require 2FA for any kind of account recovery. And so if the user has access to some of their factors and those factors could be a backup password, a sync device their mobile number and email the process is a lot smoother. So if they lose access to one of their factors but they still have access to at least two of their other secure factors then the account recovery process is going to go pretty smoothly but we also do enforce a waiting period that can be anywhere between one to four days depending on which factors you still have access to. And so if the user doesn't have access to some of the more important phone numbers or factors like phone numbers then we consider phone number an important factor here because so much of 2FA is still done via SMS. We do have additional requirements to allow them to change their phone number or regain access to the account. And so while users may be annoyed at some of these restrictions people tend to be more understanding about additional frictions when it comes to security products. If you're somebody that's taken the effort to sign up for an authenticator account then you're probably somebody that cares a little bit about security and is going to understand that this is something that's necessary. Next let's look at GitHub and GitHub is an interesting one. Fortunately I've never had to go through the account recovery process there but they have really extensive documentation about their 2FA setup and recovery process. And they also offer a lot of options for recovering your account. So one option here is recovery tokens. So make sure that you save your GitHub recovery token somewhere that's the easiest way to recover your account if you lose access to your primary form of 2FA. They also will let you fall back to SMS if you choose to do so. You don't have to fall back to SMS and I think that's an important distinction. And that would be if you have a stronger form of 2FA enabled like TOTP or WebOPN. They also do an interesting thing where you can configure your Facebook account to store recovery token. And this is an option that Facebook allows. You can get more information about how GitHub sets this up in their docs that I have linked here including the recover accounts elsewhere link. And so that's an interesting way to kind of store a trusted token on another device. The downside of this is that they assume that you have a Facebook account. They offer plenty of other options for you if you don't have a Facebook account. But the upside here is that you're able to, you know, you're probably more likely to be able to access your Facebook account than you are your GitHub account if you get locked out of that. But interestingly, I wanted to tell this anecdote. A friend of mine went through the account recovery process with GitHub and said kind of in line with this warning that's shown here. They told her that she could unlink her email address so that they could use it again to create a new account for her stuff and then in six months if the old username was still dormant they would release it to her. And so that's a pretty extreme form of a waiting period but that is one way that they can kind of slow down the process of an attack or taking over a trusted GitHub username. It's pretty extreme. It's pretty unforgiving six month waiting period is pretty long. And I don't know if that's true for all accounts. Maybe their account was especially high risk but definitely make sure that you as a, you know somebody that might be working with developers and working in code yourself have some recovery options configured on your GitHub account. Speaking of Facebook though, one option for account recovery on Facebook that I wanted to highlight is somewhat unique or at least tied to the features of that product. And so Facebook is interesting because they allow you to nominate three to five friends that can confirm your identity before giving your account back to you. And so this is a pretty cool idea. If your product has a social component like Facebook this could be a reasonable solution. I don't know if I would recommend building a social component just for this but that could be something that if there's other reasons that you have that in your product this could be a way that you could build account recovery and it's also a way to think about what are the unique aspects of your product that you could use for account recovery. One thing challenge here is getting users to set this up maybe a challenge. I'm not much of a Facebook user but I did so I had to dig into profile settings to find this generally. You don't want people to have to dig into profile settings to find these types of security features but maybe they haven't prompted me for it just because I don't log on very often. So those are some examples of what different companies are currently doing. And now I wanna talk through some concrete recommendations of what you can do through your company. And so the first one is that you want to have users register more factors than they need for everyday login. And so this is true both for one FA or for two FA but the benefit here is that you have additional trusted factors to compare against when the user loses access to one of their made login factors. And so the more factors that you have access to and the more factors that user has previously registered the more confident that you can be the right person is trying to gain access to their account and the higher chance that the user will still have access to at least two of their factors. And so generally if the user is logging in with two FA you wanna make sure that you're verifying at least two factors for them to regain access to their account. So you could register these at sign up that's a pretty guaranteed way to make sure that the user has these on their account or it could be during a different authenticated session. That's also really common. Get users signed up as quickly as possible and then have them add additional security later if they start to become an active user of your site. Requiring users to register additional factors at sign up is going to create some additional overhead in that process. If you have the notion of like a sign up or a growth team you might wanna be talking to them about how they're implementing this and how it will affect your registration numbers but it's definitely justifiable in certain use cases. If you're doing any kind of financial services or anything that is going to have a level of fraud detection and in place for creating making sure that people that sign up are real users. That's certainly a use case where you could have them register additional factors. ING Bank for example supports virtual video calls to verify new customers. But if you're an internet retailer you probably don't wanna be asking a user to upload a government ID. Another recommendation is that you do wanna design your recovery process based on the value your business is protecting. And so this means that you want to do some threat modeling watch Alyssa's great talk from earlier on that look at your account takeover costs and understand how much you're actually using. You wanna make sure that you're making the right level in an investment for your business. If you're in a higher value industry like financial services this could mean adding that additional friction to your recovery process but also make sure that you're considering this from your customer's perspective too. Do they understand the value of their account? So if a user is signing up for a service like Gemini you know a cryptocurrency exchange that user probably is willing to opt into more security than they would for like a DoorDash account. And this is a great quote from the security researcher Cormac Hurley where he argues that users reject a lot of good security advice but for good reason because a lot of security advice involves taking a lot of time and they either don't understand that time is a risk to them in their account that they're trying to add security measures too. They don't understand at the time they might risk losing or they might just not care. I was surveying some of my security friends about what they think of backup codes. And it was interesting because there was one person that was like, yeah I have this very detailed folder structure that I keep on a USB and a locked safe. And I was like, that's really great. I'm glad that you do that but like I'm not even willing to do that. I keep my backup codes in a variety of other places that is not that organized. But if that's something that me as somebody that thinks a lot about authentication and you know talks a lot about authentication and it has this kind of elevated paranoia compared to the average person. If I'm not willing to go to that level that's certainly not something that I'm gonna start recommending to the average person. But getting back to more recommendations you definitely want to be intensionable about who you're allowing to reset to FA or if you allow people to reset to FA. And so this is along the lines of looking at your threat model. Definitely be intentional about this. This was a conversation that I had in Twitter DMs where I was able to get customer support to reset my account completely, turn off my two FA. And that was just by giving them my phone number and my email. And so my Twitter account, it is my full name but that account is not tied to that profile at all. And so they might have done some validation there but I highly doubt that they did. And I'm not saying that like this company shouldn't be letting their support team do this but like I was wary enough of this that I don't want to tell you who this company was. And so because I'm more paranoid than the average person you know, this is something that I was like a little wary of but from a service perspective it was really easy to deal with. So there's that trade off but I'm not really sure like whether or not this was the right answer. And also the reason that I had to reset this this is just like completely a side note but the reason I had to reset my two FA code for this company is because it's not a company that I log into very frequently. And I wasn't getting any two FA codes sent to my phone. So when I was trying to log in they were like, check your phone, we sent you an SMS. And I tried to do that and I just wasn't getting any SMS tokens but it turned out that I had set up this account using AFI. And so all the two FA messages were telling me to check my SMS messages but they were actually not doing that because I had set up a TOTP token. And so that's just like a kind of a side that if you're one way to like help hopefully prevent two FA is to be clear on the messaging when you're sending two FA tokens make sure that you're sending them and messaging that you're sending them to the channels that users actually have configured. Another thing that you can do is prompt users to confirm information that could be used for recovery when they log in. And so this is one way that Twitter does that. This is the same idea behind things like security checkups and email notifications to review your account. I mentioned that digging into profile settings probably isn't going to be a very good way to get users to update their security settings. These types of prompts are one way to get users to either add additional factors and make sure that the factors that they have registered are up to date. And these reminders are relatively cheap and easy to implement. And this is especially compared to the cost of what a customer lockout or account recovery would be. Another recommendation, more than general prompts is that you can also time these reminders and get specific with them. And so time them around the holidays and around new iPhone releases. This is something that, you know, from the off the side of things we always see a higher volume of support tickets around the holidays when people get new phones and around new iPhone releases. And so that's when people are changing their phones. That's when they might get locked out. It makes a lot of sense. Like there's not really anything too crazy that's happening there. But an example of this is an email I got from Save Year last winter as just reminder to save your recovery codes so that you don't get locked out of your account. You know, all things used to be one of the only authenticator apps to support backups. That's no longer the case. This may be less of a problem now that more authenticator apps are starting to support this feature. And you know, usually when you change a phone at least in, you know, a lot of Western countries you don't change your phone number but this is something that in some countries people, you know, don't use their phone number as the same type of identifier and don't have that kind of static identity that we think of here. But even actually Google Authenticator just rolled out a token export feature for Android. It's not totally the same as the authenticator apps that support backups but it's one way to make that process of changing 2FA tokens between phones a little bit easier. So another big thing, hopefully you're already doing this if you support 2FA but you really want to make sure that you're designing your 2FA onboarding well. And so in a 2018 study that focused on the usability of Ubiquis, researchers found that setup success varied a lot depending on the platform that customers were trying to log into. And so users logging into Google had an 83% success rate of enabling 2FA but when they were trying to log into Facebook they only had a 32% success rate of enabling 2FA. And one thing that's interesting is 19% of people actually locked themselves out of Windows 10 because the system allowed them to enable the factor without ever doing a successful verification. And so a lot has changed since 2018 but I think this study is a really interesting look at how onboarding UX impacts user success. And so it sounds obvious but make sure that your users are completing at least one successful authentication before they ever enable that factor. And finally, the last recommendation that I have that you want to make sure you do is add waiting periods to deter hackers and give users real time or real users time to dispute any takeover attempts. Remember that your solution is not going to ever perfectly prevent attacks but in most cases you're trying to build something that's basically going to discourage people from trying. And so like Alyssa Miller was saying earlier in her talk about threat modeling, I think the goal here is to slow down an attacker and this is one very explicit way to do that. And this gives you as the website and as a service time to respond and protect legitimate users. So this is pretty common for high risk account resets. So GitHub, this is their notification that account recovery may take up to three to five business days. And so because this is business days you can assume that maybe there's like a real human that's reviewing some of these. Maybe they send these to their security team for review, I'm sure it's some kind of at least semi-automated process. Gemini which is a cryptocurrency exchange enforces a waiting period on any kind of withdrawals just for a password reset. And so this is not even resetting your second factor but this is one of the factors if you're resetting it and doing an account recovery here they're still enforcing that waiting period. And then I just kind of wanted to throw in some ideas into the ring for debate too. I already mentioned automatically emailing backup codes really curious to see what people think about that idea. We kind of talked about trusted contact authorization. Curious to see like if people have tried this and what the downsides are that's not something that we've decided to implement but I think it could work for the right context. What about like something like link site authorization? This is what Keybase pre Zoom was actually trying to do. The idea here was that if you know my account foo website is the same person as my Twitter account if you already have those linked could I tweet something that builds some kind of trust that I am the one that's trying to log back into foo website? That's certainly possible. Like I don't know how reasonable the implementation there is. And then one of the last things that I wanted to kind of talk about was SMS fallback. Like I've heard a lot of debates and had some debates about this whether that's a good option for recovery of a TOTP or hardware token or whether it defeats the point and it might defeat the point but I think it's better than nothing and it's probably going to lower overhead for support and that's something that's always important to consider too. So my general advice there is like offer SMS as a fallback option but don't make people use that as a fallback option. You wanna really delight your security conscious users and so GitHub does this like they offer SMS as a fallback option but you don't have to opt into that. You don't have to opt into SMS as a 2FA channel if you don't trust it. And of course, you know, what about blockchain? I'm just kidding. Please don't save your compute resources for something else but you know, debate that if you want to. So you know, I did mostly wanna focus on the positives here but I do have a couple of things that you shouldn't do. Don't for instance, let people only use one factor to regain access to accounts where they have 2FA enabled. We saw a wave of account gets hacked because they were protected with a password and SMS based 2FA. And then the attackers were able to sim swap the customer and bypass the password because they had a second factor even though the users had strong passwords. And so that's something that you really want to avoid. And also just like, please don't be this company. If you're going to disable the second factor on account recovery, honestly just like don't offer 2FA at least send a fallback message to the SMS. In this case, like I did still have access to my second factor for some reason I just hadn't saved the password in my password manager. And finally, don't let this discourage you. There's a lot of ways that you can think about designing this but don't give up on 2FA. This Google research shows that even SMS codes sent to a recovery phone number helped prevent 76% of targeted attacks and up to 100% of automated bots. So this is really good coverage and protect a lot of people from account takeover. Just put a little bit of thought into designing this process and you'll be golden. So like everything, this will depend on your business but here's some of the things that you might want to monitor as you adjust your 2FA onboarding, as you adjust your user experience and think about designing that and how you do recovery. Definitely be friends with your support team and make sure that you're aligned on how much friction you're forcing your users to endure because support costs may go up as a result of adding additional factors as a result of adding additional security to your authentication process. But that's okay if it's actually decreasing the relative amount of compromised accounts or the losses that you're suffering from account takeover. So I really hope that this talk is giving you some ideas for how to think about your account recovery processes. Again, my biggest thing here is that there's not a right answer here but I really just want you to think about it. Think about what's right for your business. Think about what's right for your users and adjust accordingly and introduce the right level of friction. So if you have any questions, please add them to the Slido or you can reach out to me on Twitter, this is my Twitter handle. Once again, my name is Kelly Robinson and thank you for listening. All right, the first question is from a bravely named user, Godel, I think. How is email a solid solution to store backup codes? If email is down, everything will go with it. Yeah, exactly. I didn't say it was a solid solution. I said it was a solution. And so like with everything, like you're gonna have to balance that against how usable it is. The benefit of that is that users are probably more likely to have access to their email account than they would to whatever piece of paper they printed out when they originally like store their backup codes. And so like this is one of those things that like I don't have the answer here. I don't know if there is a good answer for backup codes. I really want somebody to do this study. Maybe I'll just have to, you know, work with somebody in academia to design that myself. But yeah, I mean, there's a lot of benefits of like usability in these solutions. And so that's something that you're just gonna have to decide whether or not you want to take the risk there. Gotcha. All right, so next one. If I sum it up, register three plus factors for 2FA, right? Yes. Awesome. All right, at this one, I'm actually very interested in myself. Should we roll our own 2FA or use a third party provider? Or maybe if I can rephrase that, if I may, what are the risks of rolling your own? Yeah, I mean, it depends on what you mean by roll your own. So it depends, there's like some factors that are gonna be a lot easier to implement yourselves. Like there's a lot of libraries out there and most major languages for doing things like TOTP. You know, but that's something that's a somewhat complicated solution. Like you're gonna have to start dealing with things like time drifts and what you do when somebody gets locked out of it. Obviously I am biased since I work for a security vendor that offers 2FA. But the thing that you're gonna have to keep in mind is that a lot of channels like SMS, you're gonna have to outsource the actual sending of the messages anyway. And so, you know, one of the benefits that people end up coming to us for is because Twilio offers that, you know, kind of as a built-in solution. And so, you know, definitely like look at your options and see how many people you have available to support this, like anything that's with a build versus buy situation. Like you probably will have to do less configuration and less code if you buy, you know, or at least partially buys a solution or an API like we offer. But the risk to building your own is that you're going to have to think about a lot more edge cases and then you're going to have to probably have more people around to support those and also support people when they, you know, get locked out. One of the other reasons that, you know, like a company like Twitch ends up coming to us for their 2FA is that we support the end user support when they get locked out of their accounts where they end up calling Twilio's account security team or Twilio's support team instead of Twitch's support team. That makes a lot of sense. Never have I ever been screwed over by a time drift. All right. So next one, how widespread is hardware token support? So you see this a lot more with internal like enterprise employee security right now. It's, you know, hardware tokens are based on top of something like Fido 2 or U2F or Web Auth N which are all like vaguely under the same umbrella of support. And not every device like or not every website has support for that yet. And so it's not super widespread, especially on the consumer side, but like you will start to see this a lot more with, you know, internal employees support and that kind of thing. And that's because it's a lot easier for the account recovery, honestly. So if you lose your hardware security key, like there's not like a lot of good ways to get past that if you want to make sure that that's something that is used to log you into an account. And so what a lot of people end up recommending is that you get two hardware tokens. And so you essentially have the same factor and then a backup duplicate of it that you would keep in an account or something. And that's, excuse me, that's gonna be something that's really hard to get a lot of consumers to do because there's a lot of overhead and setting that up. And, you know, there is a huge risk there. If somebody loses that token, like are you going to let them use a different factor for recovering that if they don't have access to that? So the short answer is it's not very widespread on the consumer side yet. I think that will start to change as more devices that we already have, like our phones adopt the WebAuthn standard. Google started doing this with Android phones, but right now, as far as I know, Android phones are only able to be a WebAuthn compatible authenticator for Google websites. Gotcha. So, Sorry asks, location can be an unseen factor. For example, when I went on holiday and wanted to log on to an app on another device, it wouldn't let me do that. How can users be informed? So there's a lot of these types of like silent authenticators that are starting to be introduced. And this can be part of like a biometric type authenticator that's basically using things about who or where you are to try to suss out whether or not that's something that we are comfortable with, letting you have access to things. The problem with these is that they're not transparent to the users. And so users can't really configure the settings around these. We see some exceptions to that, right? Like bank fraud is a good example where you can tell your bank, hey, I'm going to be traveling to X country for the next two weeks. Like if you see activity on my card there, don't like turn it off. But outside of banking, I don't know of a ton of examples where companies let you explicitly like give permission for that. And so that's going to be something that's challenging from the user management side of this. The other problem here is like, there's just like less, we don't have as much confirmation on this yet about whether some of these biometric authenticators, like there's some debate about like whether voice recognition is a good use case or a good authenticator for, we see this a lot in like over the phone support. People are trying to use this to help like save time in phone support. But there's also been studies that things like voice recognition are proven to be racist. And so is that a good option if you're going to be discriminating against the set of your users might not be. All right, I think we have time for one last one. It seems to have to deal with a bunch of the other ones that I'm seeing. What about FIDO U2F? So this is kind of what I was talking about with hardware security keys. So this is, you know, U2F is the universal second factor. And I think where we'll start to see more of this converges in FIDO2, the whole goal around using web authentication as a factor is that we want to replace passwords. And so we still might have two factor authentication, but the major factors that we're going to be using will no longer include a password. And so I don't know if like U2F is going to be the term that we're going to be using going forward. I think, you know, just for semantic purposes, web off-end and is going to be like, well, we'll see a lot more of. And to that point, like I think as the devices that we already have, like our phones start to become trusted authenticators, like we'll start to see that pick up a lot more because I'm not as likely to like lose my iPhone as I would be likely to, you know, lose a hardware security key that I only use to log into a handful of websites perhaps. And so the challenge there is like, how do we use the backup? How do you register another trusted secure factor in case somebody does lose their phone? Because that's something that, you know, we definitely have to deal with right now and giving some level of control to the user of what they want to allow as a trusted backup and trusted recovery device. In the case of lost phone is going to be something that I think we'll have to start explicitly giving users control over when they register those factors. Awesome, thank you so much. All right, thanks so much for being here again. Wish it could have been physically in Montreal. It's been a really great talk and thanks for closing out the afternoon, evening, whatever time is at this point in such an awesome way. Really appreciate it.