(bright upbeat music) - Thanks Ron, it's good to be here.
I'm really looking forward to talking about WebAuthn today. We'll look under the hood, see how WebAuthn works, how the login and registration flows work, why it keeps us more secure.
And we'll look at a bit of code as well to see how the browser talks to the hardware authentication devices.
My name's Ben Dechrai, I work for Auth0 as a developer advocate Auth0 are the identity in the cloud company. So if you use Stripe for payments, for example, you would use Auth0 for authentication login, single sign on things like that.
I've been a software developer for 20 years, and in that journey, I've gone from having to control all the data myself. I want to make sure that my user's data is in one place that I can keep a total control of through to realising that some software components don't need to be built by me. I should be building the stuff that makes my application different and I can outsource to cloud services, the stuff that they do really well.
And one of the things I really like about a WebAuthn and the hardware authentication devices is from an authentication perspective.
This gives you really the best of both worlds in a way, you can still outsource all of the authentication to a cloud provider without having to worry about all the security that comes around the authentication and login controls and the software and securing the infrastructure, all of those things, but your users still get to control their credentials on this hardware authentication device.
So the control of logging in and the security around those credentials is distributed amongst the users while the code that actually does all the authentication login, the access control, all of those things can still be centralised in one place. So let's have a look at a couple of different credential types and the things that we often look for in what we would term a good set of credentials or a set of credentials that we have a high trust in its performance for.
So when we look at credentials, there are probably three main things that we want a good set of credentials to have. The first one is we want it to be easy to remember and hard to guess.
So if it's hard to remember, we're not going to use it. We're gonna find a different way of maintaining our memory of that information.
And we'll look at passwords in a second as a prime example something that's not easy to remember, and the ability to make it harder to get those credentials obviously keeps us safe from third parties. The second thing we consider to be a good attribute of a set of credentials, is being easy to change.
If the credentials are breached in some ways, then we want to be able to change that easily. And the easier we can change it, the better that credential mechanism is.
And the third thing is how hard it is to intercept. So it's hard to intercept, or it's hard to distribute that information around so that people who shouldn't have access to those credentials can use them.
If that's, then that's good for a set of credentials. So I've plotted a very scientific set of performances for different credential types scientific and so far that I've just had to find whether or not, I think it's performed, not performed or somewhere in the middle.
It's not actually that scientific, but I've plotted things in a general area.
So we can kind of see how different credentials match up against each other.
The most popular one that we all know about is passwords. So let's have a look at how a password ranks in terms of ease of remembrance.
Now, technically if your password's one, two, three, that's going to be easy to remember, but it's also going to be easy to guess.
So in terms of being easy to remember, and also hard to guess, I'm gonna rank passwords really low if you have the same password, because that's easy to remember, then that's going to be easier to guess if you know, somebody's credentials fo one website, you can log into another website, just using the same username and password.
And if you make them hard to guess, then you're making them hard to remember as well. So passwords don't score very well in the, the ease of remembering and hard to guess kind of measurement there.
One thing they do score really well though, is an ease of change.
It's really easy to change your password.
If you know your existing password, or you can get some kind of password mechanism what you need to do is provide you a new password. And from a software developer perspective or the backend, it will secure that through some kind of hashing algorithm and store that in a database, technically changing a password is really quite easy in terms of intercept.
I'm gonna put that to somewhere in the middle, slightly lower down towards the young, quite so sure level, because while passwords are hard to intercept, especially if we're doing best practises, like making sure people looking over HTTPS and, we hashed them on all of those things.
One of the problems with passwords is that once they are breached, they're really easy to share. We've all heard of how have I been poned, which is like the database of common breaches or large breaches that have happened.
It's hard to stop a password being distributed once it is breached.
And we have so many different vectors as well. HTTPS can protect us from the password in transit, but what if somebody inside the organisation leaks the data or a hacker gets into the database, or there's a man in the middle of tackle, or there's an SSL issue.
There are so many reasons why passwords could go wrong in terms of being hard to intercept or making it easy to intercept that I'm gonna put it slightly below middle. As I look at SMS as another credential type. So this is where maybe you get a link via SMS that you click on, or there's a code that you get emailed to you or SMS to you. You then have to type into the website in terms of, is it easy to remember and hard to guess. Well, they're generally randomly generated every time. So I'm going to say, yes, it is gonna be hard to guess and hard to clone. And they're going to be easy to remember 'cause really there isn't anything to remember, you get the code and you type it in.
So it scores pretty highly easy to change, it's fairly easy to change, not as easy as a password if you wanted, if you're doing SMS, for example, and this could apply as well to email links like when you log into a new Slack team, rather than having to type in your password, sometimes you'll get an option to have an email link sent to you and you click on the link and that logs you in automatically, that's kind of an SMS or an email based login credential mechanism.
To provide a new email address or a new phone number to sort of receive an SMS to you'd have to register your device, confirm somehow by confirming her number that's sent to you via SMS, but your new devices now registered in the system. So changing the device that receives the SMSs is fairly easy, slightly trickier than changing your password, but not much really in terms of how to intercept. When I put this slightly higher than passwords, it's slightly harder to intercept.
But with SMS, for example, I would score that even lower again with emails slightly higher.
So just looking at this category of a message centre to have a device of yours in some way, it really depends on which medium we're using SMS, there are vulnerabilities in the network, which is essentially the way that SMS, it's the network, the mechanism that's used to send SMSs around the world.
There are intercept vulnerabilities at that level email isn't overly secure in terms of if your password, if your email is only secured via password, there's often questions around well, if you can completely log in just via email, then if somebody reaches your email account, they have access to everything.
So there are various intercept concerns here, but I'm going to say that in general, I'm less concerned about those than I would be for intercepted passwords.
And then we're looking more and more nowadays or biometric authentication as well.
So voice fingerprints, things like that, I don't remember the last time I left home without my fingerprint or without my voice, unless I've got a cold or something, but by and large biometric data about me is really easy to remember, it's always on me. And in terms of guessing, biometrics are really hard to generate or to guess. So I'm gonna score the ease of remembrance on how to guess and how to climb quite highly on here. The ease of change, however, is really hard. Changing a fingerprint intentionally to be a different fingerprint is really hard. Technically, maybe there's 10 different fingerprints on your hand, but that means you can only change your password or your fingerprint nine times.
And voices change over time as well.
So there's that aspect to take into account if you're using voice as a credential mechanism, but generally it's going to be hard to change any of these things about you.
And in terms of intercept, we're gonna score this fairly high.
If there's still possibilities for intercept, but by and large, we're mostly safe on this front. The intersect mechanism for a fingerprint, for example, there was a proof of concept some years ago where somebody took a high resolution photo of a piece of glass.
I don't know whether it was a phone or an actual drinking glass or something, but they managed to get the fingerprint into the photo. And then they converted that into a 3D model and printed a fingerprint that was then able to be used to access to some system.
It was a proof of concept, and obviously it's going to have to be a targeted attack. You're gonna have to find somebody who's left a clean fingerprint somewhere, be able to take a photo of it, turn it into a 3D model and have the ability to print it in a material that a fingerprint reader is going to think is a fingerprint.
So its really is a corner case, but if you wanted to, it's technically possible, but by and large intercept on biometrics is gonna be fairly tricky.
So these three examples here, you might've noticed they form what is commonly termed as multifactor authentication.
There's something I know like a password, there's something I have like SMS in this case, I have the SIM card that is registered to the phone number that receives the SMS.
And I have something that I am, which is my voice or my fingerprints.
And there are a number of other examples of these three factors of authentication.
And in order to make things more secure, we've already discussed about how passwords are probably one of the worst ones in terms of remembering. We write from down, we use password managers, which is one way of alleviating this, but then we've got to have access to the password manager on new devices that we're using, so it's tricky. So a lot of movement recently has gone into using passwordless, which is basically excluding any of these, something I know, factors of credentials and focusing just on the others and using those as a login mechanism.
So again, going back to the Slack example, getting an email to log into your Slack team. And another mechanism that has come in recently and WebAuthn now provides is using FIDO security keys. This is again a passwordless login mechanism, but there's one thing, the FIDO security keys, and also clients' certificates which, if you're not familiar, they're basically public private key pairs in your browser the consent be sent to the application to log you in, but FIDO security keys are basically that in a security key. So let's have a look at how a WebAuthn and the FIDO security keys fit into this.
Obviously they're also a passwordless credential mechanism. How do they rank against these three measurements that we've been looking at in terms of ease of remembrance and hard to guess they score really highly.
They're easy to remember because they're devices that you have with you or they're built into your phone or your laptop. They're hard to guess because the way they work as they generate signatures of challenges that are sent based on a public private key pair, it's really hard to duplicate that public private key pair. So for somebody to be able to recreate a signature that your hardware authenticator would create is going to be mathematically improbable.
I'm not gonna say impossible, but it's gonna be a lot of hard work.
It's certainly harder than any of the other examples that we have here at the moment.
In terms of ease of change, it's similar to changing or re registering a mobile phone for SMS.
You just register a new hardware authentication device in the application you're trying to log into. And if you need to, you can then decommission the old one. You can actually have multiples as well.
So you could have multiple hardware authenticators. You could have the one built into your MacBook pro the one built into your mobile phone, and you could have an external one as well. If you need to log in from another machine somewhere. So you can have multiples and any one of those will then authenticate you into the system. In terms of how to intercept again, scores really highly. It's very difficult to intercept.
And one of the added benefits of the way that WebAuthn works is it actually looks at the origin of the website you're trying to log into.
So not only is it hard to intercept, it protects you against phishing attacks.
So as a single credential mechanism at scores Rebo, so I've mentioned that it protects against phishing attacks, and we'll look at the registration and login flow in a second.
But before we do that, let's remind ourselves what a phishing attack is, so that we can see how the WebAuthn flows protect us against that.
So we have a user let's say to you, for example, we'll put you in green because green is the colour of a good person.
And we're all good people in this room.
So you come along and you get an email or an SMS, and it sends you, for example, it's a message from Google, and it says, hey, you're almost out of space, you need to upgrade.
So you click on the link and it takes you to the Google website, to your untrained, spongy brains.
I, you don't notice that it doesn't actually say google.com, but it's a phishing attempt.
It sent you to a different domain that looks similar. So the page looks fine, it looks like the Google login page, see, provide your credentials and immediately upon providing your credentials and hitting submit, you get sent to a convincing, but fake confirmation success page.
Meanwhile, in the backend, the credentials you've just provided to this phishing site site are sent to either a person or more likely a script, which is gonna take those credentials, pass them straight into the Google server.
And then it's going to allow them to log into Google as you, so they now have access to your account.
And meanwhile, you're looking at this fake login page or the fake success page.
Now, you could actually redirect to the person to, or you could be redirected to an actual Google page. And the likelihood is you're probably actually logged in already.
So you wouldn't be asked to log in again, or if you were then maybe you'd think, oh, maybe I've got my password wrong or something, but having a fake success page actually helps against the multifactor authentication steps that can sometimes protect us.
So let's say for example, you have gone to this fake Google site and Google then notices that some of this person in red, this some malicious attacker is logging in. Maybe you're in London and they're logging in from Berlin. So they will send you an SMS saying, hey, it looks like somebody is trying to log in, enter this code into the browser.
So your browser then gets asked.
It prompts you for the authentication code. Now, the thing is if you weren't actually logging in, you'd think, hang on a minute, that wasn't me. But the thing is you think you were just logging in. So you're gonna provide those credentials to the browser, which can then also get sent to the attacker. They can then use that to confirm the multifactor authentication process.
So essentially what it all boils down to is that phishing attacks are basically aligned fake login pages.
They're aligned on the inability for a human brain to easily discern between two URLs, especially if they're average web users.
If they're not software developers, or then they're not security professionals, they're even less likely to notice that the domain doesn't match what it should. So let's now jump into the registration and login flows and see what WebAuthn does to protect against the fake login page scenarios.
So let's say this is me and I'm trying to log into your website.
So I go to my browser, I type in your domain. And I click on the, I want to register a new account button. So requests get sent to your server and your server then responds on a provide a username, I say, I want to create new account.
My username is Ben.
And your sever says, that's great.
I'm not going to return to you a challenge. So rather than providing a password, when I created the account, what's happening here is that I'm saying to your server, I want to create a new account and your servers replying saying, hey, let's build a password together.
So it sends me this challenge and what it expects is a signed version of that challenge.
So the browser application then receives that challenge and communicates with the hardware authentication device and using the navigator.credentialsAPI built into the latest browsers.
They'd cause the create method on that navigator.credentials.
And it passes into it, the challenge that was sent from your server and also the web origin.
So if I made your domain.com, it's going to say, this person is logging into your domain.com. This is where the phishing attack is basically nullified, because if somebody sends me a link to a site that looks like your website, but there's actually some other domain.com. Then when I create the signature and the next step, the web origin is gonna be some other domain.com, not your domain.com.
So immediately we've stopped the ability for the hardware authenticator to be able to create a signature for a website other than the one that I'm currently on.
Unlike human brains computers don't get confused between the domains.
So the next step is that the challenge gets sent into the hardware authenticator, the hardware authenticator then creates a new private key pair for that web origin specifically it'll then take the challenge and sign it using the private key.
It'll instal the private key locally on the device that doesn't get sent back to the browser, or look at sent back to the browser is the public key. And the signed challenge, the browser then takes that public key in signed challenge, and basically passes it straight to your server. So your server has now in the first step received a request from me to create an account with a username, Ben, and then it responded with a challenge and the response that I got back, was a signed to challenge, and a public key, assuming that public key matches the signature on the challenge based on the challenge that your server sent in the first place, you can now manifest locally, a user that stores the, public key for future verification during login processes. And also as part of that comes back an ID, a unique ID for that public key.
So that's the login process can be assisted. Let's have a look at that one next.
So when I log in, rather than sending just the challenge, because I've said, hey, I want to log in.
And my user name is Ben, you can then say, well, Ben's already logged in.
And he has a private key locally with the ID ABC, for example.
So that sends back the ID as well as the challenge. That ID and challenge are then passed through to the navigatorcredentials.get method.
so get to takes the same as the create except that it also receives optionally IDs of the users that are about to be logged in. So, because I've told your server what my username is, you can tell the browser to tell the hardware authenticated device, what the idea of that user is.
So how do I authenticate a device now having had this get method called, takes the challenge.
It uses the web origin in the first instance to pull out the private key, and then it takes the challenge and it signs that challenge with the private key.
And it will return that back to the browser via the response from the get method.
So the browser now has a assigned key, assigned challenge that it can then return to your application. So this response here only sends to the sign challenge, and there's no public key anymore because the public key already exists on your server. And you can then receive that signed challenge back and say, well, we know that Ben logged in.
We know what Ben's public hears.
We sent this challenge and we have the signature, does their signature match the public key? And if the answer's yes, then Ben has just successfully logged in.
So that in a nutshell is, the flow of how the registration and login mechanism works for a web authentication.
Let's jump into a demo and see how this works in the flesh. And we'll have a look at a bit of code as well. So we have [email protected] website, which is a tool created by one of my colleagues. And it'll take you through the process that I just walked us through in the presentation of providing a username and registering an account, and it'll show the flow on here as well, because I've just gone through that.
I'm not going to repeat it, but what I do want to do is jump over to the debugger and we'll have a look at the actual code that gets gets called from the browser to the web, or the hardware authentication device, once the login or the register button has been clicked. So this is the point after the server has responded to us with a challenge.
This is the point at which the browser then calls the hardware authenticator.
So we have here the navigator credentials create method that we saw in the presentation, and we can provide into their username and password or username rather, not a password.
So we'll create a test user for now.
And we've got a couple of extra parameters that we can provide down here, but for now, let's just create a new account and see what happens in terms of the data that we get back. So I'm gonna click register, and it's gonna ask me what type of authentication device I want to use.
I'm gonna use a built in sensor on my MacBook. How about just tap that there.
We can now see that the response that we've got is this raw ID? So this is the ID that you would store and then send it back when the person wants to log in again. And that's essentially what you need to store. If we then go through to authenticate, we can see that it's pulled out.
This is the raw ID here.
It's pulled that out as part of the debugger of this application for convenience.
So what would normally happen is I would send a message to your server saying, hey, I want to log in as Ben.
And then you would find out that, or in this case test user, you would find in your database, this raw ID, and you'd provide that back to the browser. And the browser would then talk to the hardware authentication device, the FIDO WebAuthen device, I would say, hey, I want to now get a credential. I want you to essentially sign this challenge based on this credential that we have here, the ID 016, blah, blah, blah. So what happens is that the hardware authenticator is gonna take this ID and use that pull out the private key.
Make sure obviously that private key is also a set up or configured or was created for the website you're trying to log into at the moment. And then when I hit authenticate, if we just looked down here to scroll a bit further, so we can see the output and I tap the laptop again, we can see that the authentication has now succeeded. We have a signature that's come back that can be sent back to the server and the server can then use that to verify whether or not the user is logged in.
Now, there's one thing that I wanna show you in particular, which I'm finding really exciting about WebAuthn is we looked before at how WebAuthn can be Passwordless one thing that not all the hardware authenticator supported yet, but one thing I really like the idea of is username less authentication as well.
So imagine being to log in without having to provide a username or password. So let's say for example, the request is made, let's create an account first, with user nameless enabled.
So we'll create an account for Alice because whenever there's any kind of authentication going on, Alice and bob are always around, and then here under the authenticator selection, I'm going to enable require resident key.
So what's happening now is that user ID or the ID for the key that gets stored on the server that was sent back, that was then given to the hardware authenticator saying, Hey, we want to log this person in.
Imagine if that was stored on the authenticator itself. And we were able to get the user to select which ID they wanted to use to log in at the time that they're authenticating to their hardware authenticator, we'll actually do a demo of this.
So it might be a little bit too vague at the moment, but let's delve a bit deeper, but essentially that's what this checkbox here is doing is telling the how to authenticate, to remember the key essentially store this locally as a user.
So we're gonna register Alice, and I'm just going to touch that fingerprint sensor again, And now I'm going to do a hard refresh here, cause I want to reset this form so that we're back to default.
Now, let's say that Bob comes along and Bob wants to create again, and we're also gonna make sure that he has a resident key locally.
So this is a situation where two people might be sharing the same key.
Obviously at this point, you need to trust each other 'cause essentially Alice can now log in as Bob, but it might also be useful in situations where you want to have multiple accounts within the system. So we'll now register Bob and we have Bob in here with his or raw ID, which offers are going to be different. Now, if we jump up to the authenticate tab here, we'll see that because I did a hard refresh. The debugger forgot about house, that's fine. The debugger currently knows about Bob cause we just created this account.
So you can see here by default, it's suggesting that we want to log in as Bob, if we don't tell the web authenticator, which credentials we want at all, if all we do is we say, hey, we want to get a signature for this challenge, do the rest yourself.
Then when we come in and we click authenticate and I tap the fingerprint reader here, without asked, do you want to log in as Alice or Bob? So even though Bob's been remembered, we could come in here and say, I want to log in as Alice, just by clicking that we've now got here, the raw ID, that was created for Alice and the signature. So now we've got a user less user nameless and passwordless authentication based on public private key, signing of a challenge.
I think it's really powerful stuff.
All right, so I hope that's been a really good deep dive into the flows, into the reasons why WebAuthn exists about how it stops phishing and that it's probably going to be one of the, it's a new technology as with all new technologies, It's going to take a little bit of getting used to this UX experience issues that we've got to work out about how our users use these hardware authenticators to login. Obviously you'd need to make it easy, but I hope that this has given you enough motivation to go and try and play with the WebAuthn APIs built into the latest browsers.
I'm looking forward to any questions you have, and I'd like to thank you for your time.
And if you wanna get in touch with me as well, email me, I'm also Ben Dechrai on all the social medias with the icons listed just there.
If you want to find out more about Auth0, head to ben.sc/Auth0 and webauthn.me, debugger that I was playing with just now, is that ben.sc/webauthn or just weauthn.me, thanks.
