G1234! - Deploying WebAuthn at Dropbox Scale: Second Factor and Beyond - Brad Girardeau

excellent thanks for coming everyone we're gonna be talking about web than today so how Docs supports it for second factor using it next what comes next for login and generally looking forward to telling you about it it's first a quick disclaimer I do work for Dropbox on the product security team and I worked on the web on end project is that certainly informs my talk but all opinions are still my own I'm not actually here speaking on behalf of my employer out of the way let's start with the quick user story so let's say I'm working on a presentation perhaps I want to get some feedback on it could be based on a true story here

share it with my friend they receive an email might look something like this nice blue button to click on go ahead and click what happens come to this website use your name password click Sign In now I can view the file so how did this website actually figure out this was my friend my friend had access to my slides well it's that password that was really the only secret part of this and if we start thinking about what we actually want out of a secret like this that authenticates us to a website controls our accounts one key element is that we don't really want to tell it to people that's kind of a strong secret

you're not telling it to everyone you're keeping it really restricted to only where it needs to be and unfortunately passwords are not so great secrets since you're in the passwords track of b-sides you may be familiar with this but you're always entering them on websites you're essentially telling this web form this website all the time this is my password please authenticate me so this of course leads to problems because it relies on me it relies on all of you to not mess up to not just once put your password into the wrong place so if we go back to our example maybe you're used to putting in a password if someone shares a file with you so you can sign in to your

cloud provider of choice so someone else an attacker can rely on that to send you an email that you know looks like someone is sharing a file with you looks like it redirected you to the right place but it's of course really a fishing site so all of a sudden your password has been told to the wrong set of people to the wrong server to an attacker they can compromise your account that's one problem with passwords the other problem is just that you have too many of them and we're not actually good at remembering long random strings of letters or numbers so typically you know you might choose an easy to remember password which often

means easy to guess so with that you also end up with both fishable secrets that secrets and week secrets now you know some smart people thought about this and we're like we can do better we can add a second secret second factor authentication so we're probably mostly familiar with this you have an Authenticator app on your phone you have a code sent to you ever SMS and this really helps with this second case of having weak passwords are we using passwords because now you have this second secret that's a little harder to get at it's it's actually you know separate for each site potentially your your Authenticator app has a separate secret for every single site or the SMS

infrastructure generates a new one-time code for you on every login so we have the second secret where the part you're telling it only works for a little bit it's one-time use it's you know a minute long so we've reduced the risk here and really helped with the second case of password reuse and weak passwords but we haven't really solved the problem of phishing because that part you still still part you tell still works it's still working for a whole minute so if someone can just as easily ask for that part as well as your password if they're trying to fish you and go ahead and turn right back around and once again gain access to your account the key lesson

here was though that computers can actually help us to design stronger authentication schemes so we had this human problem of not being able to remember passwords one other solution is a password manager of course or in the second factor case we can rely on our phone to actually remember those secrets for us and for phishing if we want to solve that problem we can see how a browser might be able to help us with that to your browser does actually know the difference between a phishing site in a real site it might not know which is which or that one is trying to be masquerade of the other but it does know their different origins their different domains and so

we can actually use that information the TR TP was a pretty good start of the authenticator apps because you know they remembered a different secret for each site for you and the weak link was really that you had to actually be the one to enter the code into the browser and there was no guarantee that you were entering into the right place instead we can offer a browser to talk to our devices directly and handle that for us as long as we keep credentials scoped to a particular domain our browser can make sure that phishing sites can never gain access to a real sites credentials because they're just fundamentally different domains so enforcing that separation and using our computers our

browser to help us that's kind of the key idea of what web ovens bringing to strong authentication and then really the rest of the talk see you know how that actually works and then how you can build on that to have strong second factor authentication and even potentially password lists lock in log in and seeing in general where do passwords fit end to this new world if we have strong authentication with web lock then you can see here kind of a roadmap for what I just said the rest of our time here and I'll go ahead and dive in to a bit more detail on what what web event actually is so we have a nice you

know technical looking specification here and this is kind of you know most specific version of like what is web uh then it's you know a specification by the w3c that outlines a set of browser AP is that websites can use to authenticate users on the web using public key credentials a great thing about public key credentials is now remember that secret part we want a secret that we never tell here the secret never leaves needs to leave the Authenticator only a public verification part is sent to the server of course the other nice thing about this is those credentials are also going to be scoped to a website as I mentioned so if you're looking at this back it can

be a little intimidating and it helps to just know first you know what's the overall structure of what what weapon actually lays out for us so it's going to give us as you know where us would be safe server developers it's gonna give us to operations here we can register new credentials to a user and we can authenticate with them and we have three main parties who we have to figure out how they're going to talk to each other and how they're going to behave so we have this server that wants to authenticate users it's also called the relying party as you'll see that in the spec now the professor mediates communication between all of these

elements and the Authenticator devices themselves so this could really be kind of anything we'll just see going forward you were talking about like UV keys hardware tokens also authenticators built into your laptop maybe a TPM maybe a fingerprint reader maybe your phone so this is kind of a wide class of things but basically anything that can talk to the browser and actually take out the undertake this protocol now if you're looking at the spec or you're just getting a bit lost if I talk through things it's helpful to remember that as a server developer you can ignore a lot of this and really as a user you don't have to worry about too many of the

details so it depends which angle you're coming in from but the spec really has to describe you know both for all three of these parties what they need to do so you can really focus in on especially at the beginning the party you're most interested in so in this case it would be the server developers for and instead of kind of going more in-depth and like specifically the messages and protocols just gonna kind of go it out a little bit of a higher level of what are some key elements both of these operations and that'll set us up for how Dropbox actually deployed web often and what it looks like for different kinds of these

options so for registration we're gonna generate a request for a new credential on the server we're going to pass that to the browser call you know navigator doc credentials dot create this is this new API that web app in specified the browser is going to go ahead and pass it off to the authenticator along with what origin the users currently on and then they're going to take undertake their own protocol it specified some and web off end the real detailed specification that looks at this side of things the browser to Authenticator is called see tap - so that's the one to look at if you're really interested in the hardware side of this in any case

it'll come back the Authenticator will go ahead and create a new key pair pass the public key and some other information back to the browser and the browser will go ahead and pass it back to the server where it can go ahead and parse and save this credential with whatever user is registering so next you've registered a credential with your favorite site you go you want to login maybe it's second factor or maybe it's login in any case the server's gonna go ahead you know generate ourselves a request call this API again the browser passes that to the Authenticator again with that origin so it's only scoped to that specific origin so if you're on a

fishing side right now the Authenticator will not see the real site it'll see the fishing site and won't use the real sites credentials then the Authenticator you know signs this request using the saved credential passes it back to the browser browser passes it back to the server or your JavaScript passes it to your back-end and now you can actually verify their response so this is of course a key piece for security you have to check that it's for the right origin using the right key pair that a user has actually the user you think it is actually it's Gracchus turd with you so there's a series of verification steps in the specular both registration and

authentication actually they're most important and authentication for registration a lot of the information is actually not like not signed or not as important because the real security comes here where you're checking the origin and credentials are correct that's the overview of how this protocol works but before we kind of get further want to interject if anyone has you know been researching web bottom and is confused by the names out there or if you do later it can be helpful to kind of see in an overarching level like how these different keywords or organizations have interacted in the development of this I'll see you over I'll have the fight or two project that's Web oven plus the C tap to spec which as I

mentioned is the piece that describes the hardware to browser communication these actually overlap a lot they really work together but they're kind of a collection there that was developed by both the phyto Alliance and w3c these came out of some earlier Fido specs that you may have heard of you to f you AF the hardware parts of those which is now called C tap one so you can see you know web Wathan evolved out of basically you to F anyway F and C tap 2 is the newer counterpart to see tap 1 where this gets a little trickier is that you can actually mix and match these so you can have the browser API you know you're

calling the web offline browser api's but the browser is actually talking over c tap 1 maybe to an old legacy you to F based Authenticator so there was kind of a lot of carrot and actually to how these could all be somewhat compatible as much as possible what you miss out in that case is some new features of web by then only work if you have a seat app to Authenticator so hopefully that helps if you see you know someone marketing oh this is a fight or two or a web app an Authenticator it's a hardware device that means it speaks C tap 2 if you see a website saying hey we now support web

on 10 that means they've moved from the you to F it browse your api's to the web on 10 browser api's so for this yeah sorry let's that's better had not as loud but yes sorry about that Thanks yeah great so we kept of this section before we move on you know if you were feeling a bit sleepy cat and hopefully you get a wait cat for the next section here but in any case that would connect essentials or just web authenticate you with some sort of Authenticator device Authenticator devices could really be anything that talks to the browser over this protocol and can store credentials and the browser an Authenticator are what's working together to make sure

sigh it never gets real sight credentials and I want to talk about where job box comes in so if you look at you know 2014 2015 Dropbox had second factor authentication TOTP SMS and you know for all the reasons mentioned you know wants to do better we've seen even still recently that kind of pitfalls of like SMS second factor the reverse resent you know breach credit announced saying hey you know we had SMS to FA but attackers were still able to bypass that wasn't as secure as we thought that's you know as you know developer at a cloud company like Dropbox you would say oh this you to everything seems quite promising fundamentally u2f is what

actually introduced a lot of the ideas that I've been talking about so far so if you've been thinking like what's the difference we'll get to that but they're pretty similar in the fundamentals especially for second factor authentication so Dropbox went ahead and implemented that you know announced we have security key support quite exciting and what happened well some users did adopt it they improve their security this is good definitely encourage all of you to turn on security keys for whatever sites do support it whether it's u2f or both in but there was limited adoption overall for our user base it's only supported in Chrome and later Firefox 58 plus but still behind a flag not on by default and

generally another key point was that there weren't that many hardware devices that users just already had that they could use for security keys for you to eff you had to purchase you know go out and independently purchase something like a Yubikey or you know any of these other hardware Authenticator devices and so this is a big barrier for getting kind of mass adoption and what's really hopeful about web offending this initial effort of u2f and getting the whole ecosystem one board saying we're gonna have more and more devices users already have like their phones like their laptops have web authentication we're going to support this protocol in all the major browsers not just Chrome so

that's really the biggest reason to go from you know if you have u2f support and you're thinking about going to webblock then like that's the biggest reason is it's the future and that's where this strong authentication is going and you know this might seem at first like is this just marketing is there like you know anything of substance to this like there also is as well but it's not to be unlike discounted this kind of ecosystem adoption because that's really going to be the thing that actually makes it feasible for users to use this on a broad scale and actually be like the commonplace way of authenticating to sites on the web it's what's basically connecting

websites to hardware devices in a scalable kind of mass adoption way of course we're not quite there but that's the hope of the future and then there are also some differences in the protocol there's some additions and new features so kind of the two main ones are that you have more options over a credential creation than web often so you have a little more control over what kinds of devices or credentials users might use and you can also have authentication that works without usernames it works without needing to say hey these are the devices you registered before which do you want to use to authenticate you can just send a request to the browser saying please

authenticate a user and it will come back with some sort of cryptographic proof of some user device that they previously registered with you including their user ID so with that in mind you know you don't have you to F a site doesn't have you to F it's really time to just skip to I bought then there's already more browser and device support and it avoids some complications we'll get into when you support both at the same time so I have a quick video here just to kind of demonstrate that there are already starting to be new devices there which this specifically is going to talk about is showing like touch ID second factor on a MacBook Pro so the

new touch ID bar today if you get Chrome can bethe Chrome and turn on a flag you can actually register touch ID as your second factor and so eventually you can imagine using web offender login as well or second factor on other sites so this is a kind of screencast of what that looks like on the actual touch ID bar as well as the prompt that came up that's a pretty exciting thing webathon unlocks for you you know already coming up in the next couple months and just see how to get there and how you know we had a solid u2f implementation what really changed gonna go into a little bit just like what is actually new a

little bit more detailed level so even if you're not you know planning to directly do this hopefully it still can kind of illuminate what really changed here and what web authenticate level so in u2f you had some identifiers for your website app ID you had you know I want a challenge you know register request so it has a challenge to make sure that request is fresh and you had some registered keys because you didn't want to duplicate people you know registering the same device multiple times and in web Botham you know it's lined up color coded to be what kind of corresponds there so you have you know relying party has an ID that replaces the app ID you

have a challenge you have some credentials and then you have a lot of new options that's the part in purple so we'll talk about some of those a little later well signing also pretty comparable now one new option at the bottom there's user verification this is a nice addition where you can actually request that an Authenticator has done some sort of check that the user who's using it is the one it expects so if you imagine like a Yubikey or hardware token if anyone steals that they can still just use it and press the button the button doesn't check that it's actually you know you pressing it whereas you just saw touch ID that'll actually look

at your fingerprint so there was some verification by the Authenticator there that you are who you say you are if someone steals my laptop they can't just use my touch ID Authenticator because they won't have the same fingerprint so that's the new option in web life and to request the other thing to look at is that you might see the app ID and the relying party ID are different formats and this is actually causes some backwards and compatibility because from the device perspective since those are different formats it looks like a completely different website and since the protocol is pretty privacy-preserving across origins and also to prevent phishing it'll treat those as totally isolated sites and

won't let you use credentials from one with the other so to get around that so people don't have to all we educate our old devices there's actually an extension in webathon called the app ID extension so you can specify a legacy app ID to use so users can still keep using those previously registered devices but that extension doesn't exist for registration so if you have a device registered with Web authen it's not going to be useful in older browsers with u2f but if you have already u2f registered devices those are going to be usable in both with this app ID extension this does have a few confusing edge cases the main one here whereas like let's say you have

a user they had a fight our u2f key registered and they lost it so they got a new key makes sense they go in they register their new key now it's on a new browser we've switched a web authentic and you know in this case we'll say they forgot to delete their old key now a little bit later say they're at a library they're at a friend's computer they need to log in and get some file or get something out of their account they log in on an older browser that only supports u2f so you know if we're using Dropbox in this example we'll see this and we'll say hey they have a u2f registered key so let's go ahead and

prompt them to use that they don't have any u2f registered keys could send a separate error message and say hey sorry your key doesn't work in this browser but in this case they do have one that'll work so let's prompt for that but now the user sees this they think well I my security key I'll tap on my new about then registered security key and okay so what happens now it comes back and it looks like a completely different site to that web authentic cuz the app ID is so is a different format so it'll say hey there's not actually a credential registered that like wasn't found it's not registered and so if you just present that same era

to the user now it's kind of confusing they're like I just registered this key what do you mean it's not found so in this case you can actually detect this might be happening you can't know for sure it's possible they just actually did you know try to use a key that's not registered at all but if you think it might be happening you can go ahead and give some other error message explaining this case yes that was something that Dropbox did for that as well the other thing to think about when you're switching from you to f2 FN is looking at something called attestation so this is cryptographically verified information about the device and u2f it's provided by default if you

have a UTF implementation you've been receiving this attestation and it can be useful to see like device capabilities like will this device be useful in mobile or also if let's say you have an enterprise deployment and you've given all your employees you know a particular model of Authenticator that you trust and you only want them to use that one on your internal site you can actually use attestation to require that so there are some uses there and but in on you know kept broad public-facing sites there's less need to have it be like cryptographically verified or to enforce things like that so it's actually not provided by default if you're you know if you look at what Dropbox actually

does here it does request this information you'll see you like do you want to provide your make and model of your key but it doesn't enforce that it's provided or cryptographically verify it because there's not a need to actually you know she wished tricked the devices users are using it's more to guide the you know product user experience around you know warning them if their device won't work on other you know a mobile device or something like that or just providing better UI to show what devices are being used the nice thing about Web Wathan you know if you're even thinking okay this is great I'm gonna have more authenticators touch ID you Ricki things like that and you

know do I have to do a lot of work to actually support these new devices and the answer is no that's it's really nice the browser actually does almost all of the work especially if you don't care as much about at a station because that is one area that can differ between device types the only other real thing you might have to do is just add support for a new you know public key private key signing algorithm so usually that's just a few lines to like translate the web and of it to your favorite cryptography libraries version of it so one example is pretty recently Microsoft released you know Microsoft edge in a preview Edition that integrates Windows hello

face sign-in pen sign in with webblock then and so this to make this work on Dropbox was just a few lines of code to add a new signature algorithm and then it was ready to go so if you have a you know preview build of Windows you can also try this out for second factor so now that you know we have this implementation you know new wrapper libraries that choose u2f and webathon be stunned by your support you know tweaked the format's a bit for each case did all the processing time to roll out so went ahead rolled out second factor on both Firefox and Chrome and you generally want to do second factor off first

not the registration part of it because if you already have u2f especially you can always turn off web often and go back to u2f but if you have people registering new web often keys you won't be able to use those with u2f authentication or signing so it's not compatible that way so typically you'll roll out your authentication piece first test it with you know some internal registrations things like that and then when you're feeling solid go ahead and roll that out in this case Dropbox rolled out to Firefox and later chrome when web authentic real most recently as I mentioned Microsoft edge preview Edition is ready to go so you might be looking at this fancy new web often

experience and see you know some link at the bottom that says hey like can't use your device want to get a TR TP or sms instead and your anything will like okay that seems like an issue like couldn't someone just tell me to fall back to those and I'd still be tricked so the answer is not ideal I agree but unfortunately web often isn't actually everywhere yet so hopefully in the future you know it'll be able to be web authentic still pretty difficult to get it web off and working but that'll be coming soon you know that'll be coming Dropbox has a desktop apps that's its own kind of separate piece of work to actually integrate web authentic re

still doesn't have support for web both in as well so you know this is something that hoping to be coming soon but still you know there has to be a balance between this increased security and just locking people out of their accounts they need to have access but if you are determined you know you only need to know you know use web authentic you could you know sign up for TOTP and then just like throw away your tea or TP seed but this of course is pretty risky in terms of you would want to really understand where am I able to use web offended Isis and where aren't I so stay tuned here for for updates but that's

the current state no so just to recap what Dropbox has done so far and then what we'll talk about for the last part of the presentation here rolled out web authentic and factor you know you can - it's pretty well understood based on people's experiences with u2f kind of how this this flow these slurs should work so generally pretty good there there's a few tricky parts if you already have a few to eff with this backwards compatibility stuff if not just skip to web off then that's what Dropbox has done so far and then now I want to you know kind of okay that's where Dropbox is now more of my own opinions of speculating unlike okay what

comes next how do you get from the second factor authentication to an actual primary login experience how do you go password list potentially what's the future of passwords there as first just to look at it at a technical level you know why first you know web authentic is actually pretty useful for validating that you want to do web offense einen because at a technical level they're almost the same the specification doesn't actually make like a hard distinction in its basic operations of registering and signing between the cases it's really about using the options that it provides you differently in some cases so one example of this is like in authentication or signing and the second factor case you

would generally always provide this allow credentials field because a lot of older devices to save space would offload storage of their private keys to the servers they would you know first encrypt them with the private with a symmetric key and that was the only thing the device had to remember it encrypted the new private key it generated and then passed that off encrypted to the server where it could store it then the server had passed that back in the allow credential field and the device would then on the device decrypt it and recover the private key and actually use that the sign so this was kind of a nice hack to save onboard storage on these little

Authenticator devices this of course doesn't work if you don't even know who the user is yet you can't pass in these allow credentials but web authentic seat app to specify something new called I want a client resident key so this means that private key is generated you know on the device and never you know it's actually stored on the device it doesn't need to be offloaded in this way to a server and then if you do that you can actually receive like a user ID back in their response that lets you see okay which user actually tried to sign in here of course you can still also do sign in without passwords but with usernames so ask for username first then

look up the keys and you know if you're just looking at like taking your second factor code and like turning it into login code one thing you might forget is that in the second factor case you've already authenticated the user with the password so it might be okay to like include something about their account to like have better UI it might make a reasonable trade-off and you might want to like make sure you reassess that trade-off if you're returning it just after a username because there's really been no authentication done that zone at that point but the spec itself shouldn't pose a problem here it's just something to be aware of if you're kind of porting

that 2fa case directly to login yeah but in general you know these basically the same registration signing operations the harder part is what policies does that that's where it gets more interesting because you want to balance users choice and like how they sign into their accounts what devices they want to use with their accounts security and also risk of them locking themselves out of their account so one example of this is maybe you've gone to a web often you know signup flow where you want to say hey the user doesn't even have to you know make a password for my site anymore I'm just gonna use web off then and so your user goes register as a device with

you registers an account and maybe they registered you know the touch ID bar on their laptop well now they're never going to be able to sign in to your site unless they have the same laptop so if they ever go to a different site you know they won't have the same you know this is like a platformer authenticators what it's called they won't have the same platform to use so they won't be able to chill a thin 2k so in this case there's clearly a high risk of kind of lockout if they lose that device or they're just somewhere else so you might want to then say hey you need to register like a roaming Authenticator

is what it's called and actually you know force them to register some sort of like hardware token that can be removed and moved and moved around between devices or maybe eventually like a phone would serve this purpose although right now most of the phone operating systems aren't quite there yet so that's one example there the other is that if you have a you baqi that's just you know test of user presence is what it's called it's you like you press the button but it doesn't actually verify the user is who they say you would want to be hesitant before letting users have that as their only like authentication factor because it's really easy for that

to be lost or stolen and in the case where it's a second factor that's that's not too bad because they also have to know the password but here like if someone you know if you have login through just plugging in a ub key and pressing a button someone could go ahead and like try that on all of the major sites for like you know common accounts and just like see what they find and so it's a bit riskier to have like no form of user verification at all so that's those are some examples of policies the other one I mentioned was like in an enterprise deployment you might want more control over say you know if you're

using biometrics maybe you don't trust biometrics and you want to say okay actually don't use that or maybe you only trust you know certain devices that you've already handed out how their biometrics work so you can go ahead and use some of the other options in weboth in like attestation or some of the there's a few other registration options to select different types of authenticators to enforce some of those policies so kind of just to summarize - they're really the two main questions or do you require user verification I would tend to say this is you should otherwise it's pretty risky but you know it's still something you could think about and also what sort of restrictions on

device type whether it's platform or roaming whether it's a specific model or brand in general for like a large public deployment you probably don't want to get to in the weeds with having to keep up with all the different devices but you know they're hard cases where you know certain categories of devices and distinctions based on them would make sense another example is like on iOS authenticators like hardware keys you're only going to work if they're Bluetooth enabled because right now there's no NFC support so that's you know so you might want to make sure someone registers a device that's usable in iOS but that's some questions that would be up to whoever implements it so we have some

you know ideas you got to set some policies but it's pretty you know it's understood we're working out what the best policies are we could get to a world where there's definitely you know it'll be possible to sign into a lot of websites using web off end without a password so what happens to the password what are kind of the use cases that are still hard to like know the answer to right now or directly get rid of so one is recoverability what happens if you lose access to all your devices like something catastrophic happens there's a fire or you were carrying everything that authenticated you to a site and a backpack that got stolen

who knows you lost access to everything and how do you get back into your an account so though thanks thing about a password is that it's in your head if you have managed to remember it and you know it's possible to remember a few strong passwords even if it's hard to remember one for every site you know you it's still in your head you can use that to log in from anywhere so if you're without any of your devices you can fall back to that more easily than you know what do you do in the web authenticate around the cyant you know password list case so there are you know some solutions for for certain cases here

like you can fall back to your email if you're not an email provider of course there's another new specification that's pretty cool that's being developed that's called delegated account recovery so this is something right now that like Facebook and github support where you can recover your github account through your Facebook account and it's actually also like privacy preserving so the only thing the two providers know about each other is that you have an account on the other provider but they don't actually know like what the username is or what account it is so it's nice privacy-preserving way to link accounts for the purpose of recoverability so you could imagine the future this you know is more widespread

and you're able to kind of have you know one you know trust account maybe it even has your real physical world identity attached to it and you can use that one to recover all of your other accounts maybe through actually like showing up in person you know if it was like a bank you could show up in person with some other form of identification or police report or etc you could use the physical worlds responses to these kind of catastrophic circumstances to bootstrap your online identity as well so that's kind of one like future looking thing you could think about it but in general it's you know well we'll have to see kind of how this ecosystems evolves but

at first it will at least reduce the frequency and number of passwords that are needed because then a minimum a lot of sites you know you're probably fine recovering through an email account or something like that so you could just have them as webathon only and if you lose a device maybe you recover it do something else the other kind of thing people are exploring in the wealth and ecosystem is having better ways to handle like registering say a backup device that you could keep somewhere safe and then if you lose the primary device kind of automatically transferring all the credentials from the primary one to the backup one in a less painful way than having the user

like you go to every single site and do it manually because that's obviously going to be quite painful if you're actually using these for a lot of places that's another kind of promising thing that people are looking into but I think recoverability is one of the biggest reasons that passwords might stick around for a while just to have this ability to bootstrap from losing all your devices the other area just to think about is that now that we have something like web authentication it's a weak password or something like that it's not providing much but it's still it's some additional factor like do you still need it is there still a benefit there worth the

usability cost a lot of people it seems like we're trending towards a no answer here but I could imagine maybe for a few like sites you're particularly concerned about you know you might make the effort to invest in remembering a strong passphrase in addition to your device or the other way this could go is that maybe you know instead of using the password directly on the website you use the password on your device to unlock it so you have a very strong password for your device so that's probably better long term because then that password doesn't need to go over the network but it's still something to think about and the implications it has is like how do

we encourage users to like adopt weboth in you know first should they adopt this second factor authentication or should we just directly say hey you know use this to sign in does that answer change if they already have to FA enabled if a user already has a totp code and they turn on web authenticate rid of their totp do you leave it there do you get rid of it for them if you just want to think through and I don't necessarily have the answers here exactly like how much security any of these factors provide when multiple ones are being used because obviously sometimes it could be totally redundant and you don't need both but there may be cases where

you actually want these second factors us even in the web often world yeah so now kind of just want to bring it back to all of you and say you know webathon has kind of ecosystem support to bring you know the strong authentication to the masses like browsers are onboard harder vendors are getting there but we still need more just websites adopting it users turning it on showing that you know people actually value it so it's all now on to all of us to kind of push this forward and push web authentic it's relatively like easy and well understood for implementing for 2fa so go ahead and do it the log in with device you know

password list flows also you know seem to be getting closer to at least being tried out places but the best practices around like usability and policies we're still figuring that out so you know help figure those out as well and just generally we can all look forward to fewer passwords less fishing and more account security so all in there if anyone has questions Thanks [Applause] yes thanks I'm curious if you see the need to either keep track of white lists or black lists of devices in this case just given that the devices are so new if you find a vulnerability in one what are you guys done about that kind of thing yeah so so far we we haven't seen

the need for that there haven't you know necessarily been you know widespread vulnerabilities that have been publicized for a lot of these it is a good question and kind of an example of why some of that attestation information is useful sometimes to potentially be able to do that but it's definitely a big cost that in general you don't want to undertake unless you feel like you have to so so far it hasn't been something that we've or that you know I would think is really necessary at the moment

thank you for the great presentation the problem spaces that you identified here are problem spaces that I've traditionally seen addressed with password managers right phishing yeah and you know passwords being shitty what is the you know how do you see those two how do you see this working with password managers like what is the strategic relationship you envision with this product yeah that's a great question because there they do solve some similar problems often especially if you look at like autofill and relying on your password manager to make sure it's only Auto filling on the right domain so it's certainly possible to imagine one incident some people have talked about this actually is it's not

like necessarily my idea is to have sort of a password manager but instead of storing passwords it stores your private keys for a web and then communicates over well often and the advantage there is then you still don't have to have this symmetric authentication with passwords you can actually have like more usable public key authentication so servers there's less risk of a breach of a server because now the only thing there is the public keys so that's certainly one path that could take to have more adoption in general and maybe be easier to use I'm not you know sure you know how much that'll take off versus just signing in with devices like your phone that you already have I think

they'll probably be a mix of both like I'm sure someone will create something like you described and it'll also be up to websites to decide do we really care if users are storing keys and hardware versus software and for many websites the answer is probably no actually like we're just happy that users are storing secure things somewhere instead of not having secure passwords but there there could be some cases where you do want to actually still enforce some sort of hardware security as well

I have a very similar question to that is you were my business is very interested in in web auth but our challenge is the portability of the keys between devices because you know we have entire helpdesk dedicated just swapping out replacement laptops I know this is more of a higher-level thing but what is your personal opinion of of how that portability of these keys should be approached because I've seen in the past people have said oh you know we'll just we'll store it on the device it'll be hard lock into a TPM or something and and you'll have to re re register but you know we have employees that are probably on you know 30 different sites

and we can't we can't have them locked to a device like that so I was just wondering if you could go even further into into your thoughts on that kind of problem yeah definitely a difficult problem there are people doing work on it now I was reading like a cool paper someone proposed a scheme to help with this problem essentially like you said where basically you could imagine starting to like sign chains of like you have the old device you know be able to sign for the new device and maybe like have that pre registered or some scheme like that so the keys can still stay on each device but you could get some sort

of chain of trust I'm not like describing this in like great detail obviously or exactly how it would work but people are thinking about things like that to help with it personally I guess I don't have a strong opinion on like keys have to be you know in hardware to have like improvements over traditional password security but at the same time I do like when keys are stored in Hardware because then they're less vulnerable to things like malware which is a bit outside the you know main threat model I've been talking about but it is still something that's quite nice to protect your credentials as much as you can so personally I'm definitely willing to have a bit of usability cost

to have my keys on like something like a Yubikey where they're hard to extract but at an ecosystem level then I would hope we would be able to develop some sort of solutions like where maybe you can chain these devices together somehow or have it be bit easier to automatically register a new device using an old device now you know I've seen so many times in it you know the first iteration of 2fa is often the SMS and I also often see the websites fallback say oh you don't have your key you don't have this other fancy thing I will just have SMS does I know this it's out of scope but what is what

is the response to to how calm and just fallback to SMS is when it comes to web off then yeah I think it's really the fact that it's it's still new enough that SMS just has a broader usability kind of support out there like we have a phone the cell you know network will get a text to the user and that's going to work whereas maybe their phone just has no way to talk to a web Authenticator that they have so it's a big challenge right now to kind of develop things that are both you know usable in all of these cases and secure so my ideal would certainly be that you can enforce you

know web often only you to have only and it just takes more work to get there to make sure any users who say opt-in to that are aware of like what it means for what devices they can log in on and also hopefully pushing all of the hardware vendors or browsers that don't yet support it to support it so it's not a problem so webathon will be fairly ubiquitous and you won't need to have some sort of fallback like that

it's a quick question really is it possible to identify if the website is using you to F or whereabout and because probably hardware tokens are now you know available for Volga yes so it's possible just by looking at basically a JavaScript API is there using now in practice you know given how JavaScript code is minified etc I'm I'm trying to think there's like a really quick way you could like immediately see it but it's definitely it's definitely like visible to the user because it's code running on their browser and oftentimes you can like look in the network responses and see what you know the challenge format looks like or something like that or just search for you know

they're using you to F or navigate or dock credentials get the other way to test it is just and actually the easier way I guess is in Firefox you can toggle you to F on web authentication you know spoofing to depending on the site yeah I don't know if that means I should stop no that actually means I have a question Oh excellent yeah you by the same token you've got about five minutes so is there a way to like for example and I'm new on this would it be a good thing if you could have your hardware token but also have a way to back up so if your hardware token gets destroyed you can go

to your vault and rewrite a new hardware token with the correct data yeah that's I think that's definitely one reasonable solution to the problem with the the caveat that like now there's a new area to attack on that hardware device right if if someone if there's some way to backup the keys malware maybe you can also do that you know so how do you prevent that you know maybe there's solutions here of like putting the device in a certain sort of like mode that like unlocks this functionality and then or like you know pairing them device to device you know a device could support that we're like you buy to it automatically you know pairs itself in

some way and then like after that you can't pair it again or like that so I think there are ways to work around some of the security implications but in general that's it's definitely one possibility I recently read a write-up of Google's advanced protection and then they have like a titanium version of that or something and I think the advanced one requires that you have two tokens and now that I know the difference between web authentic done they're actually supporting UTF the the original Fido spec but with Bluetooth so that it doesn't do the UE key NFC any I guess the sort of generic question do you have thoughts on Google's approach to that and that they're not supporting weboth

and it looks like for that higher levels account security and yeah just yeah no I think I think it's great Google advanced account protection like that is kind of a u2f only mode I think did kind of make some good trade-offs around the usability issues like forcing users to register a key that is on you know is he going to be usable by their iOS device because it supports bluetooth and Google you know doing the work to add that support into their apps on the mobile phones too you know undertake the u2f protocol from a mobile device so overall I think it's a pretty good approach clearly I would like to see it move to

web authenticate more browsers support on desktop you know just generally for all the reasons I mentioned I think you know one of which released web often wasn't ready to to be used for this sort of thing u2f was still really the the only thing to use for that sort of thing so that is why it started there I think also if you look on like web offenses you to have support on mobile there there are more existing like mobile code libraries support right now for you to F it's a little easier to do you to f1 mobile then web authentic that'll change pretty soon I'm sorry would hope they were moving towards that yeah well awesome yeah cool I think

we're out of time for questions so thanks so much I'll I'll be around as well if you have more Thanks [Applause]