G1234! - Why FIDO Security Keys & WebAuthn are Awesome - Jen Tong

hi everyone good afternoon to the last talk in this room and welcome to b-sides so in case you didn't know we are in breaking ground one two three so I'm gonna introduce our speaker gen Tom and she will be giving a talk on why webathon Wi-Fi Toes security keys and web authentication are awesome so before we get started I just want to give a few messages and thank our sponsors we've got critical stack Val email security agency silence secure code warrior and many more and without them we would not be able to make this event possible also a quick note that this event is being live streamed so please be mindful of your cell phones and turn them off or put

them on silence so like that it doesn't disturb anything at the end of the talk we're gonna have a couple of minutes for Q&A so gonna be passing the microphone so if you have a question at the end just raise your hand and with that I will turn it over to Jen hi everybody how's it going how's your day been so far yeah mines been awesome I swear I haven't been cramming to polish the deck but that's ahead conferences off an hour so yeah so we're going to be talking about web authentication and Fido before I get to the actual content I'm going to ask you some questions because I usually talk to a slightly different kind of

audience I spend most of my time talking to software developers this is one of my first times talking at a security conference I'm excited about that so I need to learn a little more about you how many of you know what Fido and web authentication are like what these things are okay I got half how many of you use web authentication or Fido keys today 20% hopefully I can convince you to raise that number up a little bit but still better than when I go to most software developer ped stuff how many of you in like an offensive security exercise like red teaming or something how many of you have taken over an account and use it to cause complete

havoc oh good 30% in the room yeah this is this is when I really started getting into of authentication having had this experience and seeing how how fun and horrible can be at the same time thanks a lot for humoring me so let me tell you a little bit about myself hi I'm Jen Jen Tong as you heard just a moment ago professionally I am a developer advocate at Google my background is mostly in software engineering a little bit in Silicon process and robotics but for the last like eight or so years I've been doing developer advocacy which means I go around with developers and help them make good decisions in the past a lot of

this has been around like making good Google glass apps or using firebase rights but then around 2016 I started getting kind of scared of the state of security on the world and started turning my attention more toward security topics in the cloud and stuff and it's been over those couple years that I've had the opportunity to explore a lot of different stuff but what about indication is one of the things that's really kind of struck a chord with me and I think it's really cool and I hope I can share that with some of you there's a couple of really big reasons like off the top that like I think make it awesome one is that I can go to

pretty much anyone no matter what their role is whether they just use Gmail or they're a software engineer or like a CIO or something and I can talk to them about this topic and give them some actionable advice they can do right now you don't have to be a software developer to get a lot of value out of out of this this concept so I think it's pretty cool hopefully I can convince yes some of that one more meta slide a little bit about this presentation as I said most of my speaking is to software developers so when you talk to software developers about security topics you got a can start a few steps back I've

adjusted it I've cut a lot of the the flaw from the stack so I'm trying to make it leaner but it's still going to be a little bit different of a flow then you might have seen other besides talks in other words if it's not for you and you want to storm out and go find a different talk I won't be offended but I would love to talk to you about the topic later the other thing is like this is half intended to like teach you about the tech and convince you that this is actually a useful technology and the I have to convince you to hopefully use it yourself to protect some of your

accounts or maybe deploy at your organization okay let's get into actual content let's talk about context let's talk about authentication in the state of the authentication world as it exists today so despite all of our best efforts authentication looks pretty much like it looked 40 50 years ago we have logins user names maybe email addresses we have passwords we type them in we remember them kind of and the reason that's been so hard to kill us because passwords are just so usable most interesting computers have some way to input information into them otherwise they're not terribly useful there are some exceptions to that so if you can put input into it to use it you can probably

put a password in so it's very easy to implement you just take the existing user input methods and you just use them for authentication instead yayyyy authentication done move on to the next feature but we've been plagued with problems the whole time people have been choosing terrible passwords you know since the 1960s they're still choosing terrible and today I could probably update this slide but like the data is still gonna be the same nothing has changed it's sad and even way back in like the 1970s we realized that this is a problem we were really worried about people selecting bad easily guessable passwords and then some person in a hoodie coming along and guessing their password on the mainframe

or whatever and typing it in and causing those problems and way back then we came up with techniques to try and help people come up with better passwords we came up with like policies like hey use these things to make passwords that are safer and harder to guess and me with my softer developer hat on probably implemented a bunch of these things server-side because you know rules like this are really easy to write in code this is only a few lines of code and we hope that people come up with high entropy wonderful passwords like this but we know the reality is they came up with passwords like this hence the name of the track this talk is part of

and even if we were fortunate and somehow through training we can then someone to come up with a really nice wonderfully you know difficult the guest password we didn't see the other thing coming years and years ago which was they remember that password but now they have like 700 accounts scattered across the internet instead of just like three accounts on a mainframe or whatever so they take that super secure password and if it's good enough for their bank it should be good enough for their email and good enough for their employer which is exactly what gave rise to another threat people realize this is happening so rather than go after XYZ bank they would go after some fun new mobile game

or even just make a fake one all together just to harvest credentials either way they get access to those credentials a combination of breach services bad technique you know that somebody else did and then our same old friend in the hoodie comes along and starts stuffing those credentials and do a whole bunch of other services and bad things have happened ironically if like people had gone against some of our early advice and just written those things down on post-it notes and stuck into their computer and use a different password free service they might have be in a better place today but I digress but it's ok years and years ago we came up with another way to help defend against

guessing and also coincidentally against credential stuffing type of tax which is one-time passwords and they're really cool kind of cumbersome sometimes the idea is you get a code from somewhere either sent via some other previously trust previously you decided upon trusted back-channel like SMS or email or you share a secret ahead of time and use that to generate these codes with hashing either like on a mobile app or with a dedicated Hardware device and they're great and all they protect against the credential stuffing we're a much better place than we were before but phishing where someone kicks up a fake service come in to someone to type in their OTP still a problem and one of

the things I encounter with like software developer audiences is a lot of people think fishing is a solved problem if they have OTP deployed because those one-time passwords can timeout and they don't understand that like the threats have kind of moved to a head and that's not really true anymore at all people aren't using like five-year-old OTPs they're not trying to they'll just they'll just you know man in the middle and do it in real time so this is still a threat and I think that the fundamental issue isn't really about user training although user training does help a lot I think the fundamental issue is like a cognitive load because our users don't have some telepathic

link with a third-party service to transmit that secret over they're burdened by technology they have to interact with some kind of user interface and then they have to what we're telling them to do is to to evaluate all of those interfaces which vary greatly from one platform to another from one device to another and use a bunch of rules to make your best guess if this is the real site or if you've somehow been tricked into going to some Rando third-party site and although like you tell people and when they're there they're when they're at their highest mental capacity you know when you're talking to him during a talk or whatever it's like no no this could

never happen but it's still really effective the data shows that it's very effective and especially if you target and you find someone who hasn't had their coffee yet and they're in the process of buying a house and have been trained to click on doc you sing like DocuSign links left and right you can you can get around you know you can trick people into doing almost anything so we need to find a way that reduces this cognitive load and allows us to have secure authentication and that's what we're going to be spending the next 40 minutes or so talking about and the solutions obviously phyto and we'll both end what I'm gonna do now they're gonna kind of go through it a

layer at a time starting from the most abstract kind of hand-wavy levels and then adding layers of complexity and reality to it and the reason I take this approach is because if I have a mixed audience and people start to like doze off in the middle at least hopefully they got some value towards the beginning and have you know some understanding at least at this point they hopefully understand it like something does this better than a password and one-time password so to that end we're going to talk about the solution in the abstract then we're going to concrete a PHY it a little bit with Fido and the web authentic all's and then we'll have

enough to talk about using it to protect yourself and your accounts and then finally with sound left we're going to talk about implementation on your own service so that your users can be protected too yay okay an abstract solution how math can save us because math always solves her problems right crates new ones for me despite having a math minor I still find math painful it is hard but awesome and it goes back to public cubed cryptography because there are all these cool mathematical things there are several different techniques we knew to progenitor private and public keys in pairs yay and they have any property that if you use them to either sign or encrypt something it can only be

accessed if you have access to the other key and a lot of people superficially think this is just about sharing secrets but we can also use it for authentication and that's where we can start to talk about an abstract scheme where we use public key cryptography to authenticate users so for this and any other authentication scheme we're gonna have a couple of different phases and you're gonna grow tired of it by the end of this talk because I'm going to break this down into the registration phase and the authentication phase over and over and over again registration is about setting up that initial identity doing that initial trust and then authentication is about verifying that the same user who did the

registration is the one who is present so let's do some sequency diagramming stuff for registration we have a user our user wants to use some kind of service probably something cool it's probably a mobile game they somehow generated keep hair as if by magic maybe they do it by hand on a notebook you could do that it would probably take a while we don't care right now cuz we're still in the land of abstract ideas they securely transmit one of those keys over which they now declare the public key fortunately we have wonderful technology for secure transport the Internet transport layer security and if I don't know about that protocols rely on that existing for some of the

verification it'll come up later but we can't assume we toss that sticky over in a secure way the server stores that's public key yay registration is done it was easy wasn't it now we can move on to authentication so our users already enrolled essentially the public he lives at the server the private key is being kept secret by the user and when they want to log in the next time the server goes hey we did a key exchange before I'm going to generate a bunch of random characters and I'm gonna send them over to you I want you to sign them with the key that you have that you've kept private and then send them back to me so the user

does that then the server can then verify that that signature is you know accessible by using their public key the signature is correct that it matches the challenge and tada we now successfully authenticated the user so it's really that easy at the highest level but of course the devil is in the details there's like a million little corner cases where things can go wrong I just wanted to get the the highest level most abstract part of the story out first so let's take that super simple through Velva diagram let's kind of create a file let's make it actually useful to make up some new words and we're going to do that in of course the software

engineering way with protocols he doesn't leave brother who doesn't love reading protocol documentation actually like it it's probably I'm talking about this right now so to take it to the next level of concreteness away from abstraction we're gonna need a protocol that we can use to have a common way of doing this interchange that hopefully doesn't involve generating key pairs in a notebook by hand and it's gonna have something to do with hardware at some point because that's you know that is that is that intermediate part that I want people to stop evaluating with their eyes and little mental model of heuristics so let's dive into the protocol this is hopefully the part place where I save

you reading through the entire set of specification which is only a couple hundred pages but it's it's a little dense it's better than bluetooth oh gosh so once you start reading into the specification or even if you read articles that people have written about this topic you're gonna kind of hit jargon really thick really fast so before we go through that protocol and a little more detail let's do a little bit of like jargon you know glossary defining some terms so Fido 2 is be like umbrella term it is the container for all the other protocols we're on authentication and it's a little bit hairy because if you see Fido without a number two could be referring

to the standards body or could be referring to the previous version of the protocol depending on which specification document you read but if you see Fido and the number two in the contiguous word it refers to the protocol there was a little bit of renaming of stuff when if I don't take him out you have the server's you authenticate with these are called relying parties or RP all over the specs if you see RP even in like the actual message is being passed it refers to the relying party we have different kinds of authenticators we have platform authenticators which means they are built into something else more general-purpose computer and we have removable security dongle style

authenticators they're also called roaming in a few places in the spec those authenticators communicate with the user's client their web browser over another protocol which is called c tap - it could also be referred to as just or rather if the two is missing it is referring to the older version of the spec c tap one which has been like the term got rearranged the kind of rewrote history a little bit and decided that that also means u2f but if you read all docs a lot of people use you to have to refer to the overall old protocol which I guess would be Fido one now in the new terms anyway there are two different

wire protocols that the authenticators can use they're both still secure like there hasn't been any huge flaw discovered in seat one but CCAP two came along with slightly better binary encoding a little bit easier to use we also got a few more bells and whistles in the in the future set but if you have a CGC type one device it's still going to work in the Fido two spec and then finally web offense in this actually defines the protocol that is used by the application running in the web browser or the mobile app and the way it communicates with the server and some of the API is on the server side and this is a w3c spec so I

use this a lot to communicate this because this is one of the only non ambiguous terms in the entire set of protocols everything else is a little bit confusing so it's a good it's a good term to talk on to okay we have terms let's go through those same two ceremonies or as I as I like to call them dances let's go through the two dances again first registration and then authentication so now we have a slightly more concrete world our user has a little security key with themselves and I'm gonna assume that when they're registering they're already authenticated either this is happening as a result of the fact that they just signed up for your service and you're

taking them through this next step or they're an already an authenticated user and they're coming back to add a key long after the fact which is the much more common case and they want to add a key to their server though the relying party so the user goes tells the relying party I want to register a key great the server sends back a whole bunch of stuff but there are a couple things that are kind of key they send back a challenge a cryptographically good pretty long string of stuff so this is used both for the verification but this is also used as a potential source of entropy by the keys so this has got to be good

randomness I think if I go up to 68 bytes long or something out and also a relying party ID I think it says our PID and in the actual wire protocol and this should match the domain name of whatever they're communicating with that's used to help prevent the phishing once the client gets that it's gonna Rhian code it send it over to the key which is going to do a little bit of verification it's going to either that relying party matches the domain name that's visible the origin and it's going to make sure that it supports all the features that have been requested and then it's going to generate the key pair either using its

own internal entropy source or using the entropy from the challenge it's going to send back a payload back up to the relying party which includes the sign challenge the public key that is used that was generated on the Authenticator the origin that it's soft so that we can do domain verification yet again server side and a credential idea that's been generated by the Authenticator which it expects the server to store so the server is going to verify all that stuff it's going to save the public key and the credential ID for later recall and then it's going to make a counter and set it to zero which will be useful later for some reason which we'll get to

in a second okay with this registration is done you can tell the user hey you're done good to go go have fun later the user comes back it's time to authenticate let's take a look at this one again so the user goes probably does an existing method of login although the spec has some other cases we're just going to talk about the boring case everyone's implementing now they'll log in with their primary authentication a login and a password probably and then the server's gonna be like hey you have registered some security keys I want to verify for sure that you're who you say you are so let's do those two the authentication dance it's going to send over credential IDs

which you can actually send over a whole list of credential IDs you have one credential ID for every single Authenticator that corresponds to that user you want to be able to store them all to both authenticators for users you also generate yet another challenge you generate a lot of challenges server-side send it on over the user and their clients going to do another set of verifications it's going to use that credential ID drop the ID from the side it's gonna use the credential ID to find the private key that corresponds to you know that it wants to use to do the signing it's going to increment its own internal counter which is a little strange on the

first time you've authenticated because you're just you're just incrementing an arbitrary County haven't actually told it to the server yet but it doesn't need to know yet and you're gonna sign off the challenge and sign the whole whole big old blob so we're gonna send that all back with our increment encounter and we're sending the origin back over again also which gives the server yet one more chance to verify that there hasn't been anyone sitting in the middle with a different Hilo certificate and a different domain we're gonna verify that the challenge isn't via correct using our mathematical awesomeness and then there's a weird step we've verified that the counter is higher than the counter

that we have stored so the spec actually dictates that the counter is a positive integer and often is shared across multiple services on the Authenticator itself and what this kind of weird-looking feature does is it helps you detect clone keys so there haven't been any cases known yet of people cloning these authenticators but the spec actually is you know assumes that someday someone will start cloning authenticators and you can't tell clones apart if they're good enough clones but this hopefully gives you an ability to detect that those clones exist so the second time or rather the first time someone authenticates with the second device which could either be the clone or the original you can detect that a

clone does exist and you can log out the account or make a little red lights flash or whatever whatever you want to have happen and with that we have now successfully authenticated so that's the slightly more complete dance and hopefully at this point we're pretty confident now that well we can detect clones obviously but also that we're pretty good at detecting phishing we've taken the users burden of having to identify their domain name correctly and all that other stuff we've taken that part out and we're using hardware now to verify it at that that origin matches that relying party ID which is a huge win right there yay okay so now we're done with that

part let's talk a little bit about the hardware that makes this possible so there's a whole bunch of different devices out there these are the first ones that came out these are the like dedicated devices little security dongles they come in a whole bunch of different form factors and they communicate with host devices using like USB human interface device or near-field communication or if you're on iOS you have to use bluetooth which is not a wonderful experience but it kind of works and these are great at all they have some specific advantages one advantage is that they're isolated hardware so someone were to like compromise my laptop the hope is it would be difficult for them then to

compromise the key when I plug it in because these are all so small like so a lot of these are very simple devices they have a small attack surface so the hope is that that's very difficult to the the private key on here remain safe another benefit is I can move them from platform to platform so I can use the same one on multiple computers I can use it on my phone and so on so I can bring it around bring it with me and another benefit is if there's ever a hardware flaw discovered it's very easy to swap out this I just read provision and then mail out a bunch of these devices if

like a flaw is discovered in the previous batch of them if I want to change to a different vendor it's it's costly but like pretty straightforward to just mail out new keys and invalidate the old ones but the newest version of the spec also brings platform authenticators which are not as good in some ways as I'm roaming authenticators but they have a wonderful property of argue being in so many people's pockets because all everyone's running around now with cell phones that have these really awesome secure Hardware enclaves inside that are secured with biometric you know biometric presence detectors on the device and that's pretty cool that's that's better than the password written down in a notebook and this is one of

the big features invited to this it's available a lot of sites and I think it's what's actually gonna start to allow us to get some traction and get this actually deployed out to a whole bunch of consumer services okay so we've talked about the keys we talked about the protocol let's talk about the practicality of it let's talk about using this as a user today because one thing I'm hoping to accomplish by this is how please have some people some more people desktop the authenticator that's been sitting in your drawer for two years from when you drop by like a yubico table at a conference or something and actually start using it on your accounts so step one is getting

Authenticator it's there are a lot of different manufacturers of them out there yubico is an awesome one they make authenticators with all sorts of bells and whistles that go beyond just the web authentic so they're they're the little security dongles they sell come in all sorts of cool form factors but they also have a whole bunch of other features like PGP signing and like you can use it to secure your SSH it has like smart card features and stuff like that they're cool they're a little more on the expensive end they also have like your enterprise support and that kind of stuff so they're they're a good option if you are more in the open-source kind

of hackery side the one I'm holding right now these are my favorite these are the solo keys and their predecessor you to have zero which are open source hardware and open source software so you could theoretically go get everything down and go make your own run of keys modify the firmware and set it up so you know only your employees have to use the keys you gave them but you can also just buy them on Amazon from the real the first batch which is kind of nice they're cool and Google of course has a kit we think is neat it comes with two a Bluetooth and NFC one so I definitely recommend if you get them like get

multiples have a backup alright comes with the backup okay so you got your keys somehow you bumped into me at the right time and I had something hand out something like that next step it's actually registered on your important sites the first site I almost always try to earth people to do is like github or get lab both of which have support how many of you have like open source projects out there that a lot of people use remember how many or rather how many of you have commit access to open source projects that a lot of people use a couple people not too many this is a much bigger issue in software development I'll go to software

conference like 30% of people will raise their hands and I'm just scared that someone's going to go pull in their github and introduce a bunch of malicious code into it but I'm gonna take a minute and I'm going to make you watch registering and authenticating a key it won't be that bad I promise so here I am on github I'm already authenticated I'm gonna go on up go on down to settings for enabling a security key on github you have to already have two factor auth in a bold so you'll see that it's already enabled oh and just below it in the corner you can see a little webcam of the secure of the solo

key I'm holding so you go find the security key section it's usually called security keys and most services and you click on add exciting you scroll past all the warning is about getting locked out ignore those for now register your device give it a nickname you can call it solo key orhan or whatever you want to call it hit add and then this is when it's gonna start using the webathon you can see the key is blinking yellow and green which means it wants a touch you poke it and you're registered at this point you might want to go set up backup second factor authentication or register a second key but let's go ahead and use

it to log in so I put in my username my very secure super long password and in knowing that I have a browser that supports web authentic is gonna ask me to go tap the key I tap it and it's done way faster than using an OTP once you actually have these worked into your workflow it's actually way more convenient than like either getting out a t-top app and reading off the codes or waiting for a code to get delivered by email or something so not too bad about a minute for the whole flow and it only adds a couple seconds authentication each time I showed you github but there's a lot of other places are

supporting and more people are adding support every day which is awesome there's registries out there places are often really bad advertising their support for it sometimes you have to like find the secret links of the registration page which is like we'll get there but one of my favorite kind of registries are lists of the sites of support is dongle off that info which has a great name nitric you made it and you can go down here and you can go find different things by category to check to see and we can see that like email there's actually a lot of providers that pretty good support fast mail has a really good implementation gmail but some other

categories are not as happy by cloud computing Amazon Web Services has an implementation now Google cloud platform has it has a great one wink wink nudge but there are some other categories that are really sad like investing no one has support except for Vanguard and Vanguard supplementation is like not great the only support UB Cobra and keys and the only support won't keep her account come on almost so I keep an eye on those pretty regularly just to make sure that I'm using it ever I can because once you have one key and you're carrying around anyway the more places to use it the better you've already invested the effort in caring a dongle around okay so

now we're at the point where hopefully we've applied it to all of our important services our email where we keep our source code maybe maybe some place we invest or something like that things are protected things are a little happier we think it's going pretty well people are starting to ask us like hey what's that thing you're carrying around makes me say secure so let's talk about adding it to your software so that your users can be as paranoid as you so this is usually the point where I'd want to like jump out and like odana bones but to implementation on a toy application like added to my my cat picture application it's not quite there yet and

I've tried a few times I can't get a non broken implementation in under five or six hundred lines of code yet so instead I'm going to give you advice on on implementing it today if you want to go run out and deploy it at your organs or like that so the first thing is the client libraries are actually look pretty good shape now they've come a long way in the last couple years the the best way you can just search github or Google to find them but web off nal has a pretty good list of them actually and but there are different levels of maturity there are a few of them that are pretty mature now and I might trust

to drop into a production implementation the other other ones are pretty young if you are ready to go start deploying this like this is one of those projects where expect to spend some time reviewing the code of the third-party library you're including it's useful sometimes this is one of those times where it's going to be useful and the other part is the client libraries will pretty much focus on the server side component only they don't do much of the the lifting on the client side so you're going to be writing some complex web application code or complex mobile application code on your own there's not really in the libraries to handle that yet but this is

pretty reasonable the server the collaborate developers are doing a pretty good job of targeting the stuff that I think is most err prone like all the cryptography stuff is pretty much taken care of but you'll want to review but you don't have to reinvent yourself yay okay so rather than code it for you rather than take you through a bunch of slides with code snippets on them I'm going to show you somebody else's really cool website where they give a pretty nice walkthrough of implementing it and this one is on a wonderful website called web authentification and really cute graphics but the reason I like it a lot is because it has kind of the best

here's some code step by step of implementing it in JavaScript so we're gonna do that same two dances again we're gonna go through the registration dance and then getting a hand to talk about some of the corners some of the rough edges on the spec from the implementations I've done and then we're going to do the authentication step which has a bigger cartoon but less code so web authentication itself the core is just to read browser methods you need to run so it seems easy right kind of so it's just as one web browser thing you have to run to initiate the registration to start the registration process to get the browser to ask for that initial key

for registration but it that one parameter it takes is actually quite a monster parameter you have to send it a few things like one of the required ones is you have to send that initial challenge which for some reason you have to give it to the API as not as like a base64 encoded string of something but instead as an array of integers I don't know why they picked that I have not cornered anyone and ask them angrily enough yet you have to give some relying party information not too much of a surprise this includes the ID is important here the the name is just optics it shows up on the prompt the user gets but the ID should match the

origin of the domain that you're using to do all this brokering or it's gonna say like a this looks like phishing some user information which is why registration happens after the initial account creation because this is part of it you have an ID that you give that does not necessarily have to be cryptographically secure but can't contain any PII like it can't be a human readable username per the spec there's a name that it's human readable and the display name that is oddly required and the spec is also a little bit unclear on if a user profile icon is required which some libraries will make you do in other libraries to stick a random URL like

example.com in for I'm curious about the meeting that resulted in that but this is the name that's going to get bubbled up back to the user later and then you can specify a bunch of stuff most of this stuff is like the encryption algorithm you can use like there's just three that are required by keys right now and every key I've managed to get my hands on supports exactly those three so the client library takes care of some of this stuff usually automatically timeout is technically an optional parameter but all the browser's default to like a hundred milliseconds or something which is not enough time for someone to touch the key so it's really required

pragmatically sucide it's like a minute or something and then finally a really cool feature is a test ation which a lot of client libraries specified direct you have three different options here you can either do direct or indirect or none and what this does is you are querying the key itself you're saying during registration I want all the certificate on with a certificate off the key I want all the details of the keys manufacturer essentially if you set it to direct you're going to get all that stuff so this is a little bit privacy compromising because you could potentially use this to track a user across sites a lot of client libraries default to direct which is getting the

most information from the key but this will cause your users to get an extra privacy warning so for consumer facing services set this to none like you don't need to care too much about the implementation of the key they're using you might want to use direct here like use cases I've seen that are common are like you have to be FedRAMP compliance and you need to make sure you're only using FedRAMP keys that would be a case where you set this to direct or if you have a band manufacturer for some reason you can do a test Asian direct here and then use that to blacklist that manufacturer during registration so you send that off you call the browser API

and this is not actually gonna make any web requests index is gonna send a request to the key so the key is gonna start blinking boop-boop-boop or whatever and it will return this big old ball of stuff you get back a the credential ID for some reason you pass data in as a rays of integers and you get data out as a ray buffer so binary data I don't know why but you do so you get back all this binary data these are the two things you care about the most which are the client data JSON which is kind of a log of the the stuff kind of a log of the conversation between the browser and the

key so you'll want to use that for further verification server side like the anti-phishing stuff and then the a test ation object which actually contains the public key and the the certificate if you've requested it these are unfortunately not in a format that's very easy to transmit over the wire so you're gonna have to re-encode these again your basic c for encode them and either stash them in a form and submit it or use a javascript request to send it fire it off to the server and at that point the user probably has a little spinner now but there they've already tapped the button on their key the they're done with their step on the

registration and now it's our turn to go server-side and actually verify the stuff you're going to get back those two different things are going to come back at a minimum the client data which was that kind of log of the conversation between the key and the browser and we'll see what you're doing here is verifying a bunch of stuff you're verifying and the challenge is gonna get echoed back you're gonna verify that the echo challenge is the same you're gonna verify that the origin that the security key saw is the same as the origin that you see of yourself anti-phishing and but this is mostly handled by client libraries for you the more interesting stuff comes when you

get to the a test ation object we're that public key and other stuff is here you're going to decode it once you'll decode it again and you get out these arrays you have your a test ation statement this is if you did a test Asian direct you're gonna get this which has a certificate you can do your verifications to say that this is a bona fide awesome key but if you haven't set the none you won't get as much there but you look at auth data which you then have to decode again and this this decoding is actually one of the nastiest parts you're basically getting the wire protocol from the key sent all the way

back to your server which I guess is nice nobody's molested it or anything but like it's on tampered but it's still like a pain you got to like do a bunch of bit slicing to get it off fortunately mercifully all of the client libraries take care of this part for client libraries this is the first thing they target thankfully and client libraries will typically returned you a credential ID and a public key bytes these are the two things you care about and you need to store assuming the high-end library said that this is all the seventeen required steps of verification passed you want to take these two things and store them persist them in your database

somehow and at that point registration is done which happened really fast for the user but you had to do a lot a lot of stuff yourself okay so registrations on a user might register multiple keys at this point hopefully set up a backup Authenticator or something like that now they're ready to login the next time let's talk about the authentication flow the cartoon is a little bit longer but we're gonna skip over that part this is the web authentication method navigator dock credentials that get well one thing I forgot to mention you can if this method is defined that's how you know if the browser supports web authentication not you can just ask it like if this methods

there you can call it if not this browser doesn't support it like old-school Safari or something so again you have some stuff that has to be general service ID to make this request so like you either have to bake this into the authentication page or do a JavaScript request to get it but you're gonna get yet another challenge and you're gonna get an array of credential IDs this is all the different credentials all the different authenticators that are associated with that user and what this allows is it more of a kind of response time thing this allows the browser to kick out keys it doesn't recognize without doing a whole round-trip you can also specify

transports here which oddly you can't specify during registration but you can specify during authentication so if you want to prevent Bluetooth Keys you could do it here but that's optional timeout again optional base pack required by browsers and then yeah you'll call that method and you get back a bunch of blobs this time which you have to do kind of the same game you have to encode them into a format that you can send back over the wire stuff it in a form send it over JavaScript something like that you're going to get back at least these three things the Authenticator data which is that sign challenge and the counter client data JSON pretty much the

same as registration it contains kind of a log of that conversation with all the domain names and origins and stuff and the signature user handle is something that has to do with a newer feature if Ida - you can't restore user names on the keys and Fido - I haven't seen anybody use this yet so I haven't really seen it beyond toy implementations but it's cool this is one of the features that works towards password this authentication and mercifully the the server-side validation is actually much more straightforward for authentications you really just check the signature and check the counter you know push it your client library after you've decoded things a few times and hooray the user

is authenticated and if that's all gone well like your basic authentication is in good shape so with that we have a rough idea of kind of the level of complexity that you're gonna have to implement most of that code is code that people have to write every time right now which is one of the reason I think it options a little bit slower right now but I think the value is gonna start to pay off soon so a few minutes left so painful realities about doing of limitations some of this comes from me talking to people who we did in application to Google several years ago it's been awesome talking to people doing that and talking to people using

it in other places one painful reality that people first think about is what about users losing keys this is actually way less painful than you might expect you just do the exact same thing you've been doing for years when they forgotten their other authenticators and they've lost their phone or lost access to a phone number forgotten their passwords you fall back to a back to a fallback authentication this could be something that's more secure like making them go to the help desk in person and beg for a new key or this could be something that's less secure like going back to like a t-top one-time password but the truth is even if you use a less secure

backup authentication you're still going to get a bunch of the protections because those people are going to be a little confused when they get prompted for one-time password if they're used to using a security key you've now made their account safer even if you have a less secure backup another painful reality if an iOS support is still lagging this is looking like it's on the upswing safari's developer preview for desktop for Mac OS supports web off end it's a pretty good implementation yay but iOS support is still like kind of kludgy right now and requires a lot a lot of work on your part I'm hoping that'll change real soon as I said before the client libraries are young

expect to spend some time reviewing code and if you are touching this if you're doing any implementation you are going to have to open up the spec still I'm sorry it's not that bad a spec aspects Co it's actually pretty pretty okay it's only a couple hundred pages it's not like 4,000 pages like bluetooth so the last closing notes if you're gonna do an implementation I want to encourage you to make some good choices if you add support support more than one key please so that people can have a backup key because people are be pragmatic people are going to share accounts especially like you know like a social media account from a political campaign of

course 300 people have access to that Twitter account like support multiple keys and hen night dodge Twitter please that support for multiple keys only use a test ation and only limit key providers if you actually have a reason to none is none as the good default to start with unless you have a good reason to like only require FedRAMP approve keys and then with that I'll leave you with web authentic and oh and use this now as today to make them self safer whether they're a developer or security person or not so thank you so much for hanging out with me this evening feel free to say if you want to talk about this later or now let me know we have a

minute for maybe one or two questions and here's a slide with a bunch of links to more resources and the slides of themselves thanks everyone

so in the three minutes left before the session is over and we can go find parties and stuff does any more question oh we have a question microphone so you talked about adoption on the consumer side right but I was wondering if you can share any experience about internal adoption at Google of this type of technology stronger authentication yes thank you that's a great question so we did start using this several years ago at Google we were one of the earlier adopters to use it internally and it has been one of this one of the things got me so excited about it has been like night and day in terms of the threat of account takeovers

it has really reduced that risk almost completely entirely away so it is it is they're they're incredibly effective in preventing those count takeovers I don't know how much detail I can go into like I'm but where are some of the details of the different operations involving like red teaming and stuff with it but I don't want to go into too much detail there but yes they have been very effective we've pretty much eliminated the risk of are the concern about account takeovers of Google corporate accounts just by using u2f keys at the time so super effective have you looked at using the only key using the only key so it's like the Yubikey but it's got

six different places to be able to go through input and it's about the same cost of the Yubikey as well so Yubikey with 60 minutes I somehow missed the only key I need to learn more about the only key so there are some features built into it by the specification to prevent different sites from correlating you even if they both go to the same database like one of the reasons that initial challenge has to be cryptographically secure to prevent correlating accounts even if they're authenticated with the same key but I would always love to hear more about privacy privacy conscious features around this yep question oh it's also open source yay oh um so I've been wondering since I learned that

at Google implemented this to protect their accounts is that just protecting their Google account or is that protecting their computers as well what's your implementation like there so we primarily use them to protect our Google accounts but you know we have now we have good little cryptographic our devices that are that are deployed I'd have to I have to look into more to see how much I can discuss about that Oh mr. quick question so when I go to some site and it says you can log in using your Google can on your Facebook account is this the technology that they're using to do that so when you log into account using kind of federated login

like log into um like log into Stack Overflow using your Google Account that's using OAuth which is a little bit different it's a different step of the process they're doing a different dance with keys and tokens and stuff to accomplish that but using OAuth is one way to get strong authentication on providers that don't direct to support you to F or Fido you use a Fido backed account like your Facebook account which supports Fido authentication or your Google counter your Twitter account and then if that's your source of authentication then Google or Twitter or Facebook is going to go through the Fido authentication step and then they're gonna finish that OAuth authentication dance so you're just stacking ceremonies at

that point thank you great question any other questions Wow answer to all the questions well this is something you're interested in or if you have things I may have missed like one key like I definitely would love to hear from you either while we're at the conference or outside via the Internet thanks a lot for coming and I hope you have an awesome rest of your b-sides and hacker summer camp [Applause]