Simple. Open. Mobile: A Look at the Future of Strong Authentication

[Music]

thank you so it looks like a fool house which is nice this time this like it's like really in my face so I get to see no one so this should be a familiar theme sad but true obviously Mark Zuckerberg has more problems then it's using the same password data today to be fair I think all of us are responsible this behaviour well right so I interesting story an all-season sale you know you guys like gear freaks you know snowboard since they all skis and say oh nothing's not Amazon and all these boutique websites right like Evo in backcountry of all these things that go on sale and you're like ok I got to get them sign up sign in what forgot my

password and this is like it's flashing last one left right last one laughs get it before before it goes and you're like I gotta I gotta sign in and I gotta get this thing right so what do you do fastest thing to do we use a password I've used before you remember it BAM you go right so we all respond for this so many things are not in our control but when there's a username and password guarantee one day one time you will reuse it and you'll probably use something that use many times if this category is everybody's mind like oh this thing's not so important sites so let's use this one that I kind of

remember all the time so we're all very very familiar with us so what is the number one attack today to get credentials right house was just a credential phishing is really simple we all know this I'll go to a couple of phishing attacks which is actually quite advanced that even the best of us will get fished one way or another but ultimately you know users of petechiae are we're all fatigued they're like I got to do this because I want to do something want to buy something when it goes somewhere I want to basically see something right so we're all just like I gotta get to the next screen get me past the screen right and we just it's easy

for us to lapse in terms of what we need to do from a security perspective and this is a study that was put up by Google the best sites get about 45% I would argue that even I will show you a couple I would say they didn't it didn't account for some of the newer ones I would say close to 1% if you're not in your game you'll be you know 100 percent of time you probably booby fished and the thing is that even the weak ones like the obvious wants all of your scams like you know this is website just it looks bad and you put in your username password you just know you're gonna be

fished still get 3% why people were just fatigued just want to do it move on but funny thing is that it's not just getting fish the first time like the same thing as the study that they did you can fish again and again I mean 15 percent fall for the same thing again like this is insane right what has the industry done industry done says it's like well do better well we'll give you this thing then you got to go type it in again like this code right either you have your Google Authenticator your SMS coming in you've got some fancy app that you've done something but it's still fishable right so let's talk about how we how these are

still able to Fischer credentials we have to do better so I'll just dive a little bit onto phishing attacks I think it's kind of give gift for Evelyn so what we've seen today these are real attacks I'm sure some of you will run out and create your own phishing sites after this but hopefully not and so this is a email that you get a very traditional sense you can attach man now this may not make any sense to you invoice but imagine you just bought something and you just like I want to check the invoice imagine you are this can be anything write any attachment so don't think of it like just an invoice an attachment any legitimate attachment

that you have in your inbox can be malicious one period a lapse in judgment will easily force you to click on it and typically this is just the start of the you know you you you basically start the journey on being phished and so what happens now which is pretty common right we all have G count whatever counts you have and they asked you to real CENTAC 8 sometimes and you don't know why and you just do it have you considered why they asked you to be authenticated you know when was the last 30 days that you log into Google you probably don't movie do but this comes up and you are just going to

follow what the screen says so in this case you are like oh I guess I got a login again because of something security related or not security Lehighton and you actually legitimize the process because if it was a security related thing it's it's like you know security vulnerability or breach go log in again and you do it and you notice the last one which is typically most people recognize yeah why would I give you my password or my my why would I give you my phone number and so on so forth but people do type in their phone number so again when you've legitimately think you've gotten to the side you're just going to do whatever the screen

says and if you're a good web developer this is this is trivial right so obviously it's not just with Android devices it's it's Apple so this is a this is actually a real app that was developed to pop up to say that you need to log into your iTunes again like this is like when do I know when to need to log into iTunes like it just pops up and just put it in just move on right so these are round these are not made-up applications in fact you can find them and you can just type in searching for apps like these and it would just basically allow you to copy wholesale the code so break

it down a little bit more this this is one of interesting techniques which I'm sure people would go try it out later this is the abuse of the data URI scheme so you have the data that is loading on the bar as opposed to the website and you notice that the first thing that does is like it tries to trick you with like an actual URL that you are familiar with in this case it's a Google URL so obviously most of you guys intelligent you see that's kind of fishy but what I use is trained to do their users are trained to think of two things when you go online the little lock right sometimes

sometimes Yellow Sun is whatever and this URL does it match what I'm gonna go Google Facebook whatever so you see this thing you see the lock you see this okay very good but in this particular scheme there's a bunch of you know blank spaces and if you don't really look at the end it actually loads malicious JavaScript that lost this page so again if your user you're not going to notice all these things in a bar I mean you're just again securely fatigued like users are just fatigued of this time just want to get to the next page to buy something or to check an email whatever this is very common this is an this is something that

it's actually widely being used today still the next one is actually even more interesting I would say not to put Firefox on the bus but I will so this is still exist today on on firefox today so and as you know there are many different characters all of the wall and the you represent unicode and what what the industry has done is to create Pawnee code which is a subset of it with access key characters but you can still you so you can register somewhere foreign foreign sites with boiling down to s key and in this case you the domain app or calm was registered and this X an ad Papa blah blah blah and you should be

able to if as a browser you should be able to render the xn table instead of a poor calm but there's there was this bug that actually everybody had beginning last year that actually would render it as a poor calm and why is that significant well if I can pretend to be a poor calm then I can obviously trick the user even more and I can replicate everything that the site has I take wrestle of it I just want to show you because I just can't help myself here so this is Chrome you can see here I would do a reload right look it's it stays that way right do this copy so this is live page this is

Firefox see this domain that's registered under this this is live you can try it so I'm sure everybody who's like oh yeah let's go go go register a bunch of these domains and spoof things so this is a problem this is a problem it's not I don't think it's necessarily Firefox issue but this is a problem so this is the site right and then this is Apple so look at this is like come on you you wouldn't be able to know a difference so obviously this site could replicate exactly like this site no questions asked so why are we talking about these attacks well because it's impossible to get it right a lot of time the attacker just

need to get it right once and doesn't need to get it right once for like one person just need to just get it out and like get it right for like one person for everyone so other techniques that we've seen which are still vulnerable to fishing credential fishing it's mobile push story this is this is quite common now some of you've been exposed to technology said like you just you know click and then just move on right like I'm I see the challenge and I get this thing on my phone and this pop-up hey authenticate me so let's just talk about how this works so I've just fished you because you click on an email link and

you're gonna go somewhere and you say oh great fake dog in page right we've had all the previous examples on this reading and you put in username password yep great great attacker captures those easy attack and now you have pushed enable right so you the second factor which is receiving a push right so the attacker has this credential and he's going to the site the real site and then the real site says oh this user has a push okay so great so the site pushes to push the user Thakur's you know acting on behalf of the user and usually you know knowingly I'm expecting a push so I will accept the push and therefore I'm going to

login and so he gets logged into the fake successful login page and then the attacker on his machine gets to the successful login page so this is fairly trivial no rocket science I think there was a study out by the guys at fire as well this is out there now so we got it we got to do better so how do you become unfishable first thing first things first stop playing the users stop blaming ourselves if we if we've trained users all their lives to click on things why would you assume that thing not to click on is the thing you want them not to click just make sense every day you're clicking on things every day

you're opening up et email attachments they're legitimate you you're telling them not to do something it just inhibits productivity right so it's it's not good enough the technology's got to change your entire systems got to change we've got to redesign everything we can't just like use what is today and then say you know what you didn't go for fishing training this month okay you have a you have the thing on your hitch are now you gotta go go for more training doesn't work and now we not need to think about what it is that is important to the user right people want to go on with your lives to use the service so if you make it difficult you

make you make them what's the rule every site has a different password which is variety of lengths and special crafts like this is not gonna happen this is failure already happening at scale today this is this is live this particular examples live when your Google accounts if you use Google with 2-step verification this is a flow with the Android phone over NFC for the second factor and and it's just a tap all the crypto is done magically I'll talk about those and your in that's it it's a very simple single gesture right because that's what people are familiar with touch ID one you know whatever fingerprint touch tap single gesture so you got to make it

simple if if the security is difficult then you might so not implement the solution or doom to have the failures next we're going to make it secure right so these these are the the basics of the protocol we'll talk a little bit about what this whole entire authentication scheme is all about this is based on public key crypto private public keys origin bound keys so you know you have to check that you are actually going to the site you don't want the user to check the system has to check it for the user that's the key difference use the presence because Maori can act on behalf of the user you actually want a physical person to be test on the other end of

the computer and it has to be supported natively within all the operating systems and browsers that you use why because if you don't then you get to this whole extension nightmare or download client nightmare that we've all seen not very successful because if you can download an illegitimate authorized usable safe application you can also download malicious not so good unsafe application and the wall needs to think about credential lifecycle which is like here if I didn't have a pass for what else can I fall back to so we need to think about the ways to back the credential up so the vital you to have standard was created back in October 20 much longer before but was launched in

October 2014 these are the services that are live so who will view a familiar with the fighter you twelve standard some of you so this has been around for three years now I'm gonna talk about the iteration of that but these services have been magnified or you to F which is the I've just described the basics of it public key crypto with one Authenticator being authenticated multiple services and the foundation of this leads to some very interesting things as we evolved the standard so last week there was a announcements on the Fido to project and the Fido Pro projects really the evolution of vital you 2fn the fighter u2f was very centric with a with their Google systems which is

Android support on Android supported on chrome Chrome OS so it was kind of I won't say limited but it was it was what was sort of a corner bucket if this week there are much more players being announced or last week addition of additional browsers by default enabling vital to firefox and microsoft namely and the ecosystem is evolving into more than just second factor which is also talked about first factor as well as multi factor as well as no passwords and so on so forth so I'll talk about them second what is Fido to the specifications split two things up which is the client to authenticated protocol which is how the devices or the what we

call the OS platforms talk to an external Authenticator and then on your computer or your browser you talk to the services using the web specification it's a web authentication API JavaScript API and the key for this particular specification is broader adoption you want everything that you use today your Microsoft devices Windows Android Chrome Firefox they all have the support so you don't have to do anything I think it's important that you recognize that the open is important because you don't necessarily need to go write code extension clients on your for for your users which means that you can benefit from the work that's done by a lot of great people or great companies to make

this all native support in the browser and in the platform for the next couple of slides I want to just take you to this journey a little bit of how the protocol actually helps solve the problems that I laid out so clearly in the beginning of the presentation so what happens when you use symmetric keys or static credentials you can just go to a server get a breach get all the passwords just run them to any site you want right this is standard credential stuffing we play attack the first thing that we actually do in the protocol and this applies to both vital u2f so Fido u12 has the foundation of this things and I'll talk about some the new things in

fight or two but the in terms of the baseline protocol Fido too is really exactly the same it's a challenge to spawn technique and what allows us to do is that it's you can't reuse it right the challenge and the response which is in this case the service sends the challenge all the way to authenticate are you sign it with the private key onions and a catering use and you and you give it back which means that it has to come from the Authenticator if you cannot extract the private key which means that you can verify that the person has the right Authenticator because it has doing the registration the service has your public key right so

this is very standard public key crypto but the foundation of the authentication protocol has to follow these basic rules we choose to use public key for many reasons but one of the obvious reasons is that if you compromised the server you're not having a bunch of static credentials again like whatever a s keys or whatever you want you're a bunch of public keys so the compromising of the server allows almost not much use for that hacker so the challenge is upon combined with the public key is actually the critical element for the foundation of this protocol okay phishing attacks so what do we have here so phishing attacks so we talk about that I'll show you the example you can

impersonate you can get the past we can get the OTP you can get whatever you want basically from the user and just feed it back to the site in your in so this is a critical element here on how we actually prevent this without the user needing to care and that's the key word you didn't have to care about this in this new protocol what we do is we check for the origin so how do you check for the origin as part of the challenge from the server to the client and a client to the authen the client is responsible for putting the origin into the challenge or we call the client data and so when you sign it

not only are you signing the challenge you are also signing the origin which means that when you do the verification later you know it's coming from the right origin because the server can check it and the clients which in this case a KA the browser's has done all the heavy lifting for you so what you will not be able to do is to reuse the Authenticator response because it was signed in this situation for the bad site and not for the real site because the origins are different so when you get the response back you're like Bob check nope it's not acne its act whatever 3com and it will fail the verification process and the user

doesn't have to care what is loaded on the URL bar who cares because the browser is going to take care of everything for you which is the beauty of it right you want to be transparent when it is simple users ends need to see any of this magic behind the scenes now the other thing with phishing attacks is that the ability to invoke the authentication remotely is a problem and so in the specifications we've locked down that the transport bindings these are the three areas that you can communicate with the client on the device to the Authenticator now again the device could be I mean in this case I'm just showing a desktop it could be a

phone to a phone it could be whatever it is but they're approved transports are limited within a very small amount of radius space I mean I would say that loot of office is biggest radius so the attacker cannot invoke the authentication flow because it needs to communicate with the device within approximately obviously USB is USB NFC NFC Bluetooth has a slightly wider range they have pros and cons with each of these but they are bound they're not like Wi-Fi which could happen I guess if you want a button on a specification definitely not like web over the web like the push which is go when internet go too many carriers go to things in you know whatever protocol it

is in the web and then come back that's not gonna happen so here the key elements for the design which is basically making sure that the origin is going to be signed and part of the client data hash that will be signed and making sure that the users present and the user proof so they're doing the signature itself you get verification that the origin was there you get verification that the user was there so in this case there were two flags user presence user verification and the client actually checks you authenticate they will release it if it's if it's verified or present and the flags are set and then the server can verify which is this is the key element

of the design for how fido you twelve and Fido two is built the origin checking which is the critical element so that the users don't have to be in the mix so what do you get with the client I talked very briefly about client as a browser but the client can also be an application if you want to build the application it can also be the operating system in this case yes it can as well and but basically it HS that the user was there before it releases the signature text at the challenge hey this is the right challenge coming from the right server and obviously is check the origin if these things fail to happen

then you're gonna sign for the wrong thing and then the server can easily match it or get a mismatch and you are out of businesses attacker so we talked a lot about the fishing I want to talk about something really interesting as we evolve the standard so one of the things that people come to me as I present at the fight or to our story was like yeah but you still have to put in a username password which is true so we want to move away from that how do we move away from that because though the username password used in fight of u12 is not really a security signal anymore it's more like a identity signal like

is identifying the user but so it doesn't it doesn't cause the security problems but does we could optimize the user experience right and that's what we want we'll make it very simple so we've introduced a new concept in vital to particularly in the CT protocol which is we want to store credentials on the devices and when you stop credentials and devices like one of the key things that you can actually do is say can we turn a credential that makes sense to the service doing the authentication flow and why this is very critical it's really critical because if we think about the wall where we didn't want to passwords you actually need to have physical possession of a device that has

the private key and you want actually to have the user register with multiple authenticators to the same service because there's no such thing as like give me an SMS code anymore or give me my temporary passcode right because we want to move over than that wall you actually need to have multiple authenticators that can store multiple keys and we also want to think about the wall where there's more than one Authenticator in possession of the user because you're going to lose your primary Authenticator at some point in time you could use a UB key or not you can use a phone or not you can use both but the point is once you lose one of

them you need the backup and if the goal is not to go back to use username and passwords again or codes that we send over the network then we actually have to do better for these use cases so the wall that we need to live in is that your possession of an device and Authenticator could be Authenticator and device as well and you need more than one and that's very critical for the bootstrapping in the backups but we also get to what we call the highest surance when you have credentials on a device you can add on layers on an Authenticator you can either unlock it with a pin you can unlock it with some type of

biometrics whatever it is the biometric doesn't leave the Authenticator stays with the Authenticator and so this concept of resident keys allow the protocol to evolve to solve many many use cases both from industry as well as consumer as well as everything else in between so how did we do this so it's actually fairly simple like it was it was long drawn-out we were working on this protocol for the iterations for almost two years and and now that you see here it's like this is so simple why don't we think about it and we return two more parameters doing the response the ID is the credential ID it's a reference to the credential source that generated the private private key so we

know what to how to get the private key back on the Authenticator and and we return a user handle and the user handle has used information that the service can go look up why because if you didn't have the first factor to be using and password how do you know what the user is who who the user is well with credential ID as well as the user handle you can do a lookup quick and then you say okay this user has this public key I can use this public key to to decrypt the design response so with these two things we get to know username no passwords which is which is great I think for those of you who heard of my

vital you 12 story for a while you know you guys have been waiting for this so no claps this is the foundation for Fido to here's the current state of where we are the web authentication said it is hosted by w3c it's under candid recommendation so the specs are very long I I spend many hours reading it to present to do this presentation the web authentication is all in fougere with these three browsers chrome intent to ship chrome 67 with web authentication enabled by default Snow's behind some flags or I think it's under developer Firefox is a really shipping today with behind flags it's a source live but in 60 will be enabled by default edges in

development they will announced several set of Microsoft announcements this week I'm not going to pre M that but you know at RCA they're going to announce a couple of different things working with with folks like ourselves the client to authenticate protocol also the platform vendors are very very active Android is heavy in development so as Chrome OS windows is coming soon I would expect some announcements I'm not gonna again I'm not going to preempt the Microsoft stuff so you guys can go wait and - I think later today they're gonna say something so this is in full gear and and why do why do we kind of talk about this now because if you have a

look at the specification it announced the time everybody that says that they needed to go whatever no no username password or want it to be multi-factor and so on so forth this is the specification that can solve all those use cases including first factor as well and these are all going to be live products towards the end here every major platform vendors and I think we're missing a fruit company there but I'm not gonna talk about that one I think I think the pressure collectively from us here in this room building applications will drive that past a certain direction finally we have a developer program we have gonna have a lot of workshops on this thing I'm sure everybody has more

questions so how do I make my service make use of the latest protocol and we we are well on the way to provide everyone ability to code reference servers implement all the way from your host clients if you want all the way to your servers and so on so forth so please sign up if you want to get even also we have a new key then we're going to be previewing in the Developer Program which is cool and that's it any any questions from anyone yeah

very good question there are many different ideas that the services are thinking of right now in this password well I would say that there could be in the high surance case is very simple you need to do ID proofing in the non high assurance cases there are couple of options I I don't want to go to now it's really a discussion about life cycle but you could it could be a first one you know trust a first use which is like now from this point on you no longer have using it password type of situation so there's a lot of that we're going to cover a lot of those things so I'll just open design questions as we as we get

feedback from from all of you for now yes but I would say that all the services they're working with the specifications are starting to migrate like I'd say if you watch for the nostrils of Microsoft you can you can see how they are approaching this particular situation pretty quickly this week already I'm not gonna stop talking behalf but the new ways to sign up users without passwords and that's what they're building yes Oh always coming back to me with this question do I need to buy a new device yes you do have to buy a new device it's a new capability it's a new standard that we create it's a new key we're out of time thank you

very much appreciate everyone's time oh one last thing a couple of my colleagues are here if you do want if you don't know what you beaky is so you want to test out the Fido u2f specification with Gmail and Dropbox in Salesforce whatever find us and we're happy to give you one thank you very much