Threat Modeling Authentication

everyone thank you for having me so I'm gonna be talking about authentication today this is a lot of the stuff that I deal with in my day to day work but the way that I wanted to approach this is from some of the the research papers that I've been reading about this and in 2014 there was a research paper from Microsoft from a guy named James Mickens that he called this world of ours does anybody read this it's a very entertaining like short paper that I suggest that you go check out but like a lot of security research is incredibly morbid so in it he boils down our threat model to to potential adversaries so we

have Mossad as the Israeli intelligence group and not Mossad so his idea is that if you're dealing with not Mossad you're probably okay to go about your life using strong passwords as your defense mechanism but if you're dealing with Mossad well you're gonna have to go fake your own death and live in the submarine because there's not a lot that you can do so I think this is an oversimplification of the reality that we live in but as security professionals I think a lot of what we have to struggle with is how we find the balance and how much we want to complicate this type of simplification so we have to figure out where on this spectrum we

want to be between simpler solutions like passwords and more complex solutions like this this is something that he mentions in the paper and I hope it's still fictional but anyway Bojangles faces you know maybe that exists if somebody invented that come talk to me about it I'd love to hear what problem you think you're trying to solve but a more interesting paper in my opinion came from another Microsoft researcher in 2009 and this is a Hurley and the rationale rejection of security advice by users and he argues that when non-experts reject security advice they're often doing it for incredibly reasonable and rational reasons so how do we as security professionals help users avoid harm and I think this is the question

that I want to try to answer today I wrapped us into what I'm calling threat model II and authentication we're gonna talk about why this is hard why Identity Management is a challenge that we have and why authentication is so difficult how you can evaluate you the risk for your users and some of the actions that you might want to take to keep your users safe so once again my name is Kelly I work at Twilio Twilio is a communications company so we have api's for doing things like studying and receiving text messages voice calls and authentication I work specifically on our account security products so if there's any author users here totally acquired them about five years ago and

so I work on the api's for doing things like phone verification and multi-factor authentication and I also spend a lot of time in my job doing security education especially for developers my background is all in software engineering and so a lot of the the audiences that I speak to and work with our developers that I'm trying to get to care about security so this talk is going to incorporate a lot of the things that I have learned from talking to developers about authentication in my time at well yeah so let's talk about threat modeling especially for the applications that were working with I want to talk about what we're building the risks to the things that we're going

to be building how we can evaluate those risks and mitigate them and then finally some way to measure whether or not we did a good job a lot of this talk is going to focus on consumer or public facing accounts mostly because that's what I know and deal with if there's an area of authentication that's missing please come talk to me after this this is you know a 25 minute talk so we're not gonna be able to cover everything so we're also not gonna be talking about things like session hacking JSON web tokens cookie stealing and that kind of stuff so just so you know we're gonna be talking a lot about the process of

authentication when things like sign up and login so the problem with threat models is that it's very specific to whatever your business is so you're going to have to be thinking about the businesses and the things that you're going to be securing under this so I want to talk about the commonalities of the the solutions that we're going to be building and let's walk through a few assumptions with that so the first assumption that I want to make is that your users have something of value that is connected to a personal account and this is going to be the main assumption for our authenticated system the second assumption is that the user can only access that value once they are

authenticated so we want to have some kind of way to tie them to their account in a way that they can access that value and finally the third assumption is that if a success or if the Nader is successful they could also access that users value and a lot of what we're going to be talking about is how to make this step complicated and tedious enough for the hacker so it's not worth their time so how common is this this is a huge problem it dropped off in 2015 when credit card chips were introduced but account takeovers cost are back up to costing us about 5.1 billion dollars every year this may be different depending on the business that

you're in a lot of the fraud that we see is related to banking financial institutions and other type of businesses but the value that you people might get from hacking your accounts is not always related to money but a lot of this is happening because online identity is fallible and we'd like to believe that we have these perfect systems for convincing computers that we are who we say we are well that's all baked into trust systems of trust somebody mentioned in the in the keynote I hadn't heard that term before but trust anchors I really like that idea of having a trust anchor for something that we're dealing with and identity is incredibly baked into these trust

anchors of different systems that we have decided that we want to believe that they know what they're talking about and how we design those systems and establish that trust as part of this exercise that we want to walk through today so I want to break down the different types of identities that we have and kind of go through this waterfall of the different trust anchors that we are we're creating and the different ways that we're basically knowing the identities of the people that we're dealing with and so the first category this is really going to be physical identities and these are things like biometrics and these are things that we can't change about ourselves the second is government identities so

these are things that are validated or issued by the state so passports Social Security numbers and the u.s. things like that and finally what I'm calling contextual identities and so this is something that is going to be established with you know individual accounts this is the types of identities that were established a lot of times since the internet became a thing these are not these are easier to change about yourself they're not necessary really tied to something like biometrics specifically so if you're verifying identity with any kind of trusted contact especially in the real world physical identity is the way that you want to do that there's a huge amount of power in somebody saying I recognize

that person and this is a lot of the trust anchors that we have in our systems and this is how we built identities through most of the history until we started dealing in such scope with the people that we don't know over the Internet and so this is you know the the systems that we have in place now are largely because we don't trust the other people that we're dealing with and we've never met them in person government identities are one of the ways that we deal with untrusted contacts and in that sense we're passing the trust on to another body that we do trust this of course falls apart if we don't trust our government but right now

I think one of the things that we're able to do is you know you check into a hotel you give them your ID and your credit card and they're saying cool I trust the government and this bank that this person is who they say they are that they're checking into the secod into this hotel room and so in this type of situation we're essentially saying I trust that the government knows this person and finally we end up with these contextual identities that may not guarantee much of anything so a lot of online accounts fall back to identities other identities for validation um you know if you are opening up something like a bank account or something that

needs to be overly secure like that you're going to have to give up your social security number at some point you might have to send a copy of your driver's license and so you're getting back to those government identities that people need to start to validate so Trust is a waterfowl and at the end of the day we're just going back on someone's word and this is hard because we're all just trying to prove to some system that we are who we say we are we're doing this is a lot of different methods clicking in stop signs was really good a bit from John Mulaney about this definitely go check that out and we also want to prove that we're not

a robot we want to prove that were re real human and there's a variety of ways that we're doing this but the systems are imperfect and one of the most challenging things about this is that we may never know if we got it right you're not often going to meet the people that you're authenticating in your online systems through your website you may never know if somebody actually is who they say they are and we're just going to have to build our systems in a way that that part doesn't really matter so of course there are a lot of things that can go wrong with this this is another quote from the paper on rational advice for

security users and I like what he does with this analysis because he takes a very calculation driven approach to the usefulness of security advice and this is I think interesting because a lot of what we're asking of the users when we're asking them to take security advice is for their time but it's also a lot of things that they use if they get compromised it's not necessarily money like that might be part of it but you know it's relatively easy to fight a bank charge but then you're going to have to spend all this time revalidating that you are who you say you are a lot of time on the phone with somebody like to regain control of your account and he

goes on to say that like the worst-case scenario is generally what we as security researchers often think about there's a lot of security advice out there that talks about the worst case and the reason for that is that's more exciting the average case is not as exciting to deal with but we need to estimate the victimization rate for a lot of these things because if we don't the worst case analysis is going to lull us into this false sense that we're doing a lot more good with our security mitigations than we actually are so some of the things that can go wrong with authentication processes and this is definitely not an exhaustive list by any

means but the two things I want to talk about our compromise factors so these are if your credentials can get hacked guess phished brute force a lot of the risk that we come up with in these situations happens to do with somehow your factors getting compromised I included links there at the bottom for the threat model research for the OAuth 2 protocol and the open ID connect protocol and I think those are good things to go reference if you want to learn more about this because for specific SSO implementations those gave a really good different approaches to how they thought about the the risks of their systems there's also some known weak points in these authentication

systems and I want to talk about two of them because these are things that a lot of companies if you have any system any kind of contact center or account recovery process you're going to have to deal with at some point so first request via contact center if anybody has ever been to a social engineering CTF those things are fascinating and it's really interesting to see the people how successful people are at fishing people on the other end of the line and a lot of that is because we're all human humans are fallible we're trustworthy people that we want to help out at the end of the day but most contact centers don't have the same

security rigor that you might have in your online education processes it's not as easy to put like a form on your weapon through a contact center as it is to put in a on a phone or on a computer but it's also interesting because a lot of times there's really high-risk activities that are happening through a contact center so you might have in a situation where you can only cancel your account create a new account change certain personally identifiable information so there's some companies that only allow you to do that through the contact center and so you're creating a lot of risk in these situations other things that can go wrong with account recovery a lot of

this has to do with how strict do you want to make the process because you're essentially restarting this entire process and saying okay we're gonna reestablish your identity and like hope that your identity that your reestablishing is the same as the one we were using before so account recovery gets into all of these edge cases and it is one of those more obvious examples of the trade-offs between how rigorous you want to make the process for the user and the level of security that you want to achieve how many hoops do you want to make your users jump through so finally I think we can think about what goes wrong in terms of the value of what's

being protected and one of the things that I think is important is yes like this is going to depend on the business that you're in but this is also going to depend on the individual user accounts and so there's a lot more value in hacking higher value targets than there is to the lower value targets as you can see in this very official risk assessment so I mentioned that the goal of this is not to make is to make it the impersonators time not worth it for them to try to have this and so naturally there's more incentive for higher value accounts and this applies not just to the business you're in like I said it also applies to

the types of customers and value in this case doesn't just have to be money so you can be hacking people's accounts for information power and control as well so you think about this there's a lot more value in hacking Barack Obama's Twitter account and then there is to hack my Twitter account because he has a lot more power associated with that platform and this is where our strategies for authentication come in how are we going to mitigate these risks that we see first we have to prioritize this and one of the things that I think we need to remember is that users are inundated with security advice all the time and the more advice that we give them and

the more conflicting advice that we give them they're just gonna start ignoring that advice and so we have to prioritize the advice that we're giving them and make it reasonable for them to to follow the advice that we have so better yet we're going to design our systems in a way so the users don't have to think about this one option that you have is SSO this is an example of passing the trust you're going to be saying that instead I trust Google I trust Facebook to handle this authentication process also like in the keynote this morning I think you know if you're moving all of your hardware to the cloud you're passing that trust onto saying that I

trust Amazon and AWS to be able to secure my hardware better than I'm gonna do it myself it's also there's a lot of usability reasons that you might do this it's easier for people to log on but like it's it's convenient but you're also opening yourself up to a new category of vulnerabilities specifically a lot of dating apps had to reevaluate this when there was so much backlash against Facebook earlier this year dating apps had to move to things like phone verification and first party login systems because they were all on the system of only using Facebook to log in and all the sudden people didn't want to do that anymore so like everything your

mileage may vary it was something like this and so the other method that you have is these different factors for authentication and generally we break these into something that you know like a password something that you have like a phone and something that you are like biometric data your fingerprint so the example of this that we usually give is something like a debit card and a PIN number that's something that you have and something that you know in this case you know you're kind of ignoring all security advice and going back to zero factors if you're both giving out the something that you know so the biggest way that we've done something with passwords is something with

something we know as passwords and so for online authentication systems a lot of a lot of the ways that we authenticate things are with passwords so this is from a app from Samantha B they they basically it's like get-out-the-vote app but they give the very rational security advice to just don't use the same password that you're using for your banking app and I actually love this because it's telling people something very straightforward you know it's obviously snarky about the security aspect of it but you know users can resonate with this and it's also reaching an audience that it makes sense for but passwords are fallible and it's one of the worst ways that we can ask

users to be secure because it's one of the only ways that we're making users think and thinking is exhausting we don't want to have to make users think but until we all become cyborgs and implant chips and ourselves and the robots take over we're probably going to have to keep supporting passwords dealing with a lot of people on authentication I hear a lot of people being like we're gonna get rid of passwords forever and I think there's ways that we might be able to do that but it's definitely not gonna be in my lifetime we're definitely gonna see passwords stick around for awhile and so it is something that we're going to have to keep supporting one way to make this

easier for your customers is to set sensible password requirements minimum length of like 8 characters it's better than 6 but not too many and let them set their passwords but also alert them if the password that they're trying to set has been known to be compromised and one really great way to do this is through the own passwords API how many people have heard of this so about half of you so Troy hunt who is a security researcher also at Microsoft all the good people are Microsoft and so they he has this website that's called have I been owned com it's great you can go type in your email and say if your email address has come up in any data breaches

he also has an API for typing in your password to see if your password has come up in any data reaches the way that he stores that data is actually really interesting and in the more recent versions of the API he has a way that you can submit your password and see if your password has been compromised without actually giving him your password and so you can do a basic sha-1 hash in your password truncate that to the first five characters send the first five characters to him and he'll return a list of all the suffixes that match that prefix and so then you get a shortened list of maybe like 30 to 100 things and

you can search through that list to see if your suffix is there so it's a really creative way to check if your password has been owned without actually giving him your password because as much as we'd like to think that you know he's not doing anything nefarious with that that is definitely a way that people might be able to then log all the credentials that you're worried about giving up and so one of the things that's interesting about this is that this approach is also going to cover a lot of guessable or brute forcible passwords because the own passwords list has a lot of the most common passwords in it you could also expand this to do

things like not include common dictionary words I don't know how many of those are included in his list but you could build out a system like this that is pretty quick to implement alright pretty quick to query that allows you to let your users use passwords that aren't as easy to guess and so github is a service that implemented this and so now when you set your password on github they do check it against this known breached passwords list and they won't let you set it if it's been something that has been seen in a previous data breach and if passwords aren't enough then you can start to add other layers there are a lot of ways that you can add additional

factors for something like multi-factor authentication but once you do this it's not enough to just make an option for your users you actually have to get your users to turn it on and so you can make it mandatory but if you don't want to do that here are some of the strategies that we've seen that make it a bit easier for people to enable multi-factor authentication so if you put it in profile settings you're gonna see about two percent of users actually find that setting and turn it on if you make it part of the onboarding process and so maybe this is part of the login flow and you prompt them if they don't have MFA

turned on just say hey do you want to turn on two-factor authentication then you see about 40 percent of users turn it on and of course if your company has see oh then you're getting a hundred percent of adoption but that's another example of like a situation where you're probably going to have more security conscious users anyway and you're making the value of them doing that we're worth their time um one thing that I do want to mention is that SMS 2fa gets a lot of crap but it's still a lot better than having no 2fa at all so this is another great example of the average case versus the worst case and talking about the

different form factors of multi-factor authentication so we've heard these articles about how SMS is less secure but talking about the dangers of sim swapping and the ss7 vulnerabilities to the average user they're not gonna really understand what any of that means and that's just going to be another part of that you know security advice fatigue that people are facing so it probably doesn't matter to a lot of people so I wanted to talk about reddit in this context for a minute and so reddit had a security incident in August and they published this really nice report on what happened and basically what happened is that their employees accounts got compromised via an SMS to F

a breach and so the solution that they had for this too is to require employees to have token-based authentication so just a more secure form of authentication and I think this is a great solution for them because one thing with employee accounts is that you can enforce that type of authentication it's easier to require a token base to FA for employees because you have an IT department that can physically hand them there you Baqi you are paying them and so they kind of have to do what you want them to do it's a different model of a relationship than you have with some of your customers and so that that makes it easier to require this stronger form of

authentication moderators on reddit you might be thinking about how you could secure them there's somebody that spends a lot more time on the service and so they might see the value of turning something like this on again this is something that's gonna be a little bit more worth their time and finally for everyone else you might just make it an option for lurkers on the site or people that just casually comment you might not care if they actually enable 2fa and you can take this model and apply it to other industries and so if you work in banking you can start to think about how you might break this up with your customers by the level of

money that they have in their account similarly you could do this for something like Twitter with verified accounts making token-based to FA required and then break it down by follower accounts if you have over a certain number of followers then make any kind of to FA required and for everyone else make it optional let's talk about some of those known weak points and how we can address them first for requests via a contact center so Patrick Mackenzie works at stripe and last week he had this great tweet about how stripe is using a new method of authentication and contact centers and so one of the problems with contact centers is that were often asking for

identifiers x' instead of authenticators in that process and so you're always going to be asked or not always but surprising a number of times you're going to be asked for your social security number over the phone and that makes nobody happy you don't want to have to give that and so the solution that stripe came up with which i think is really clever is if you're on an authenticated web session you can basically pop up a token on that session and say hey if you want to try to call our customer support hotline here's the token that we're here we're going to be using the stripe agent we'll give you the first four numbers you'll give them

the second four numbers and now you both have this understanding that you are who you say you are and that's a really a great way to do it it does require that the support agent and the customer both have authenticated the sessions so again it's like the trust waterfall that you're a hoping that somebody has that type of a that type of authenticated system available to them and you do have to do some coordination there and when it comes to account recovery the same idea applies so security questions are often a way that we do this for account recovery if you you know don't have access to the email or maybe your phone number anymore

then you fall back to these ideas of these these security questions but you don't want to make these things that are identifiable you don't want to make these things that are available via open source intelligence so it's really easy for people to Google these things about you and so your Instagram account is giving away a lot more information than you realize especially if it's public so some of the better security questions that we have get into these various sip that aren't questions that are as easy to look up about a person so these can be things like what was the the name of the teacher who gave you your first failing grade so if you do have a

situation where you need to use security questions and I know we all have different ideas about the usefulness of security questions but in large organizations these are often still a requirement but we want to be able to make the security questions that aren't something that we can easily Google about a person and finally we want to know if we did a good job this will be easier if you had these metrics at the beginning so make sure that you're setting your goals for yourself before you take on a project like this and examples of things that you might care about overall money loss due to account takeovers the number of compromised accounts that you're seeing support

costs relative to the to account takeover losses you might not care about the total number of support tickets that are coming in if you're measuring the absolute value there because it might actually make more sense for you to have a higher number of support tickets if that's lowering your overall accounts account takeover losses and finally customer satisfaction I think you want to have a way of measuring this that also takes into account how annoyed customers are with this process so it's really easy to get depressed about this stuff I think as security people a lot of times we're dealing with this every day this is literally our livelihood so the time investment for us and thinking

about this worst case scenario makes a lot more sense because one working in security we are inherently slightly higher targets but we also have this paranoia and sometimes doing all these things helps calm us helps calm her anxieties but that's one of the things that is a little bit more rational for us to deal with this and have all these security measures than it is for the average person so for somebody that's not always thinking about this stuff every day we don't want necessarily want to take all of our paranoia's and project it on to our friends and family so this is a story that has always stuck with me Kevin Roose is a tech reporter who asked

two different hacking groups to attack him and they were incredibly successful and so he had somebody that was able to install malware on his system spyware on his system and then he had somebody that was able to really effectively attack him via social engineering but the conclusion of this story which I appreciated wasn't that we're all screwed it was that you know we have this idea of security through obscurity even a tech journalist like Kevin ruse the experts that he got to attack him aren't going to go through those measures for most people a lot of us are going to be in this situation when we're not going to necessarily have these types of sophisticated attacks

employed against us if we always believe that Mossad was after us then we'd have to go back and live in that submarine and nobody would be happy and we'd all just you know be very miserable so finally the thing that I want to point out is just don't blame users try to avoid victim blaming and instead think about some of the tools that we discussed and the others that apply to your specific industries to make it easier for your customers to have good security hygiene I hope I've given you some inspiration for how to think about your authentication systems come find me after this if you have any questions my slides are available at that link once

again my name is Kelly Robinson and thank you for listening [Applause]

you