The state of passwordless auth on the web

All right.

Thank you so much, Jess.

Thank you Thomas.

Amazing.

Talk about the cool stuff in, Chrome.

Now I'm going to talk about, Passwords cuz I hate them.

But first this is me as we described there.

I'm an amateur developer evangelist.

I'm funemployed but you can still find me on the internet in all the places under the name Phil Nash Twitter, LinkedIn, whatever.

The.

At there is of course Master Don.

Everyone's doing that these days.

So go find me there.

And I have a cool blog post on my website about how you can do that with your own domain, even though I don't host my own masterdon instance, which is fun.

So check that out.

Cool.

Passwords are obviously terrible.

But we all use them.

We all have them.

And normally I, I don't have an awful lot of time today, but normally I would spend quite a lot of time telling you about all the number of ways that they are bad.

But today I have one very succinct experience of that.

It's a video from a comedian, a guy named Nasim Hussein.

He's wonderful.

And and he set out to see what people would tell him if he asked them questions with a clipboard.

And and so in the middle of this, he asked a bunch of people about their passwords.

Now you'll see that a couple of people answer correctly by saying, no, you can't.

But eventually he gets there and gets somebody's password.

Let's go to the internet.

[Hussain] Do you have an email?

[Woman] Yep.

[Hussain] And what's the password for your email?

[Woman] shouldn't I, why.

I shouldn't be giving you this.

[Hussain] Sensible response.

It's just part of the survey.

[Hussain] what is your internet banking password?

Is it a number?

What's the number.

[Man, gives number, bleeped out] [Hussain]Okay, great.

And your pin number.

[Man] Pin number There is literally zero we can do as developers if people are willing to stand on the street and hand out their password to a person with a clipboard.

Unless we can ensure that they do not have a password, and that's where we are going with this.

So passwords are terrible, and that is my proof of that today.

So what are we gonna do instead?

We're gonna make this better.

But what we have to realize is this entire thing is based on a bunch of trade-offs.

The idea between user experience, And security.

We've done usernames and passwords and then we realize they were bad.

We know this, we've known this for a long time, and then we start adding stuff to them.

And when we add stuff to them, when we add friction to a, to an experience, it becomes a less good experience.

But maybe the person doesn't all just give access to their account away, which is nice.

And so passwords, let's look at that, like the experience in the security.

Let's see those trade.

It's actually a bad experience as well it turns out , it's not good.

It's hard to remember good passwords.

It's hard to choose good passwords.

I've spent quite a lot of my life with the same password.

I'm a one password user, not the app, just the, just a single password.

And that, that bit me eventually I got hacked into.

It was wonderful.

It was hard to choose.

And hard to remember those good passwords.

And really ultimately it the way to deal with passwords is, a password manager.

It's what we need.

On the security side of things.

Of course.

The if you don't put any rules in front of passwords and it's really easy to break them because people use the same password and easy passwords.

If you put a bunch of rules in front of them.

People can't remember the passwords.

And that's hard as well.

And then on the other side there are password leaks applications all over the place.

Just, giving their database away to people.

And and then if you've used the same password somewhere else, somebody takes that data from that, those people puts it over there and you lose your account that way.

And finally, vulnerable to phishing as well.

Of course, just make a website that looks vaguely like the website you thought you were logging into.

Make somebody do that and then you have their password.

Well done.

I say vaguely everybody's seen phishing attempts that look awful.

I reckon anybody in this room could make a really good phishing attack.

We have the talent and the ability to do that , but don't, I guess . Thanks.

So the, answer to this of course is use a password manager.

Everybody, anybody here use a password manager?

That is cool.

Yes, well done.

Everyone.

Of course.

We're a bunch of developers.

We know this.

And, once again if we're the person on the street, happy to talk give our password to somebody with a clipboard, probably not using a password manager.

Like they do, make the experience better.

It's easy to make a good passwords.

It's easy to fill those passwords in by just clicking your browser extension or whatever.

And and you're not repeating passwords anymore, you get a brand new, long, complicated password for every application.

And that increases and improves the security as well, right?

You're no longer, you have these long, difficult passwords.

They are unique per site.

So you are not vulnerable to repeat attacks or credential stuffing kind of attacks.

Although you're still vulnerable to phishing, you still have a password that you could indeed put into another site.

Although your password manager normally doesn't offer it up if you're on a if, you're on the wrong domain which is a, good scene.

It's a good thing.

Still vulnerable though.

Still there.

The problem is there was a survey Google ran a survey back at the end of 2018 that said that asked a bunch of questions about passwords and and 24% of people said they use a password manager.

So that's not enough.

That's three quarters of people standing on the street going, this is my password.

I know exactly what it is.

It's the same everywhere.

Don't worry about it.

And so we can't enforce that.

Which is a problem.

That was, that's a shame.

I guess it'd be nice if we could just make people use password managers.

We can make it more attractive though.

We can improve that.

And we can actually hook into some password managers and make it better, which I think is cool.

So this is where we get to our actual APIs and things we can do to help on this.

First off, I always like to hit up some HTML just to see what's going on.

If you have an Input element and you input you add the autocomplete, I love the the autocomplete attribute.

But it's particularly useful in this part, these cases because we have the new password value for the autocomplete attribute.

When you do that some browsers will offer up a nice secure password.

This is Firefox.

If you have new password as autocomplete, it will go, Hey, do you want a new securely generated password?

And the user will probably be like, no, I want the number, the one I know.

But it's, helping.

It's helping.

And of course, this this also leans into, that's not working.

It leans into, at the bottom there the save logins as well, the browser's, password manager which is a good thing.

It really isn't working.

Okay, cool.

And then on your login page, after you've, got the new password and you need a current password, we have auto-complete current password.

And we can add other auto completes, like username in order to help the browser and help a password manager kind of auto fill these in.

That auto complete current password is gonna, yeah, allow the browser to, to fill it in easily.

It's nice heuristic for that.

But we can go one step further.

And it turns out this entire talk is really about the credential management API, but you don't get talks accepted to conferences when you talk about the credential management API.

This is very unsexy.

The credential management API allows us as developers of applications to store and retrieve credentials using the browser's password manager and indeed other credentials as well, which we'll get onto.

I think this is really cool.

This is really cool because it allows us to take the idea of a password manager out of the user's hand and not our power users, the ones that already have a password managers, but the ones that aren't doing it and say, Hey, we can look after this for you.

The password mana the, credential management API allows you to store a credential in this case a password credential although there are other versions of this.

And if you have any password credential, which has an ID and a password that you know is correct, you can ask to create a credential and then use the navigator credentials store API to store that.

And what that is gonna do is pop the browser Chrome to say, Hey, do you want the browser to look after this password for you?

So there's possibly a bit more user education to do here, to be like, just say yes to that.

It's cool.

It's a good idea.

And once it has stored it the, real magic is the next part.

When the user comes back to log in the magic comes out.

When you go, I'd like to retrieve that credential.

You call and navigator.credentials.get and you say, I'd like the password, please, and if there's one in the system In this particular case, it's gonna pop another permission to say, Hey, user, would you like to log in with these credentials?

And they go, yes, thank you very much.

And they log in.

It's wonderful.

You can even do it silently.

You can add the unmediated true option there, and it will, if has, if it has credentials and only a single credential in this case, there's no choice.

It will pass that through.

I say silently, the at least on Android, Chrome it's like you're are being logged in as this in a browser Chrome part, but it allows you to do a zero.

Zero interaction login.

It's amazing.

And but of course if somebody specifically signs out, you probably don't wanna immediately log them back in again.

If they sign out, you can call prevent silent access, and that will ensure that there's a permissions popup for this.

But this is a brilliant thing.

I think it's, taking password management out of the hands of the users and putting in our hands, in the browser's hands and making a better experience all along.

So this is what it actually looks like.

This is on Android.

I think if you have gone through the login or the signup, you get that, same browser popup that says, Hey, do you wanna save this in your Google account?

And actually in, in, in Android and with Google, that is in your Google account.

So if you then go onto your desktop, it's already there.

It's actually, it syncs across, which is very cool as well.

And then when you come to that login page, another time it's gonna be like, Hey, do you wanna sign in as this person?

Yes, brilliant.

One click sign in.

Nobody had to think about a password for this entire time.

Excellent.

The experience is better.

We get these one click logins and they don't and, if we hand over this ability to the browser to look after the passwords, you don't need to know about them.

And if the browser has securely generated a password for you, even better.

Brilliant.

Now, of course, you don't have to accept the browsers generated passwords.

So you could still use easy or bad passwords.

You could still use your same password every time, even though it's going into the browser password manager.

So the credential staffing is still a potential issue.

And it is less vulnerable to phishing.

Again, this is a thing where if the experience is normally a one click, I'd like to sign in, and then you hit another page, a different website looks the same and says, I want your password.

You expect to be able to one click sign in.

That expectation makes you less vulnerable to phishing, but still a problem.

It's a good experience.

It's good.

So of course, passwords are bad and we replace that with two-factor authentic… or we don't replace it.

We augment it with two-factor authentication.

We expect a second factor from a user, a device, a a phone number something else that allows you to have both something you know, and something you have.

Biometrics not normally a good choice for two-factor authentication because it's real hard to change your fingerprints once they get leaked.

Two factor authentication on SMS.

Which is something I have been paid to talk about in the past, but no longer is made to look like this, right?

You get that message through saying, just fill in the six digit code, you're cool.

But what we've got from here is probably better security, but the experience, we've added friction to this login experience.

We've added steps between the user wanting to do something and being able to do something.

We now have those two steps.

We need maybe another device.

We maybe need a phone signal.

We can't do it inside a basement or in a plane.

And we can't log in there.

But the security probably outweighs that because you can leak your password all over the internet, but without access to the, device or the app or whatever that's giving you a two-factor authentication.

The, the, leaked password doesn't give away all access to your account.

It's still absolutely vulnerable to phishing, though.

You just have to the, the phishers just have to build a second step into their phishing application.

Yeah, that's fine.

And the SMS system itself asked me about this later is horribly built as things as, technology that was built in the eighties was and so there are very good ways to target SMS attacks on people only.

Useful for particularly high value things cuz it takes a bit of effort, but it's possible.

But can we make two factor authentication better?

Can we reduce the friction in the second step?

Absolutely.

First up, I'm gonna get back to HTML.

I'm gonna go back to autocomplete my absolute favorite attribute right now on the input element, my favorite element if you in a Safari browser.

So on iOS or indeed the desktop.

Using auto complete of one time code means that when that iOS device receives a text message with a six digit code in it, it will offer it up to the to the user in the autocomplete part of the keyboard.

It looks a little bit like this, like you go to sign in and then in the background you're sending that text message.

And I have to pause here cuz I was actually too quick.

Look at it.

Look at it there.

In the, just at the top of the keyboard, there's the there's the code.

It's come from the text message.

You don't have to see the message, you just press the code.

It actually submits the form for you and you're through.

So we didn't have to worry about changing applications, looking at our SMS application, trying to copy a six digit code across.

It's really nice.

And then it turns out if you have, if you are all bought in on Apple things and your iMessages are set up to work on your, iMac as well, and you use Safari as a browser then the same thing happens which I think is really cool when– it's a little bit magical when the desktop works when an SMSs come in.

So you go and log in and the same thing happens in the background.

This is the same application.

There we have an auto complete on the desktop.

Ah, it's so quick.

It auto completes on the desktop.

That video has decided to not work with me.

So that works for Safari and Apple and if you're all bought into that.

But if you're not, if you're more of an Android, Chrome that kind of side of things then the WebOTP API is on your side.

Now, it turns out the WebOTP API is just another use of the credential management API.

As I said.

This is just to talk about the credential management API.

It turns out that when you get to that login page, if instead of requesting a password, oh.

Well, ah, before you get to use this, you do have to change the text message you're sending.

You have to add this line at the bottom, which is not yeah, it's a little bit clear on there.

You have to add an at symbol, the domain name you expect the person to be logging in at, a space, a hash, and then the code.

Now, that domain name means that this op, this API will only work on that domain again, saving you from potential phishing exploits which is good.

Doesn't offer this thing up.

But here we go.

We get back to credential management API.

And in this case we don't call credentials.get for a password, we call it for an otp.

And then we ask for the transport.

And the transport is an array.

And the array can have one item, and that item is the string, 'sms' . This it's wonderful.

I think this actually speaks to the potential extensibility of the Web.

That array may be able to have things, other things in the future.

But right now it's for sms, I'd love to see this work for authenticator apps as well.

If you do that's gonna pop up a permissions dialogue to say to the user, do you want me to use the code from this text message in this application?

It looks like this.

I've got a video for this.

Let's hope the video works this time.

You go log in.

This is now on an Android device and yep.

There we go.

I'm gonna, again, it's such a good experience.

That I did a bad job recording the videos of this.

But there we go.

We actually, you see the text message at the top and the browser, sorry, the device at this point is actually trying to do a good job, but it has that kind of copy the number out of this, as part of the action and the notification, which I think is cool, but the bottom sheet, the permission sheet to say, Hey, do you want the browser?

Do you want this application to use this code right now is great.

Cuz that's, you press allow it gives the code to the application and then your JavaScript can go and submit the form, log the person in, everybody's happy.

So now if we add these things in the right circumstances, this is all a progressive enhancement as well.

In the right circumstances.

We've moved from a horrible password based login to these two minimal steps in which it's maybe a tap login and then a tap to accept the second factor.

So the experience is actually improving quite a lot.

We still have these things like if you're using sms, it needs this other phone it needs phone signal and things like but it is just a much better, much smoother experience in the in the pos in the best possible way, in the happy path.

And then the security side of things, we're still doing the two factor stuff but we've actually reduced our kind of phishing vulnerability slightly because we're using this kind of domain locked two fracture authentication API and, that kind of thing as well.

So it's looking good.

But we've got better than that.

Text messages, are a little bit old hat these days.

So we can go for two factor authentication with maybe a security key.

You see the browsers these days have built in Web authentication.

This has come in it was a couple of years ago, at least, if not three, four, I don't know the last three years or all a blur.

Web authentication is that ability for the browser to deal with a device's sort of secure enclave and and, produce like public private keys in order to secure things.

The, laptop itself can be the second factor device.

So it turns out this is just the credential management API again.

It's just that the credentials in this case are now public key credentials, public and private keys.

The private key never leaves the secure enclave of the device.

The public key is shared with the device, with the Server.

And so there's a little bit more work done here.

The Server has to provide a challenge which is just a random string and and identify who it is.

Like we need this we need the domain that it's gonna happen on.

And then we can tell 'em stuff about the user, their id, their username, maybe even the display names, make it friendly for them.

And then and, finally the sort of this just as is, like what algorithms to use that covers most browsers.

And when we do this, we create ourselves a public-private key pair.

The browser will also sign the challenge from the top using the private key and then return the public key and the signed challenge back to the server.

The server can then decrypt the challenge to match it back to the original one it's sent using that public key and then agree that this device is great.

And then you can do the same thing on the other side that was creating the thing.

You can then use the public key later.

Same idea.

We get a challenge from the Server, we encrypt it or sign it with the with the private key, send it back to the the Server and and that can use the public key to decrypt and, be happy with that.

This is really cool, but it has a couple of issues.

Now we now have a second factor with two fairly minimal steps because all you have to do is authenticate with your device.

But you actually either need an authenticator key your YUBI key or something like that, like a a, second part, a third party device to add to your applic to your laptop or even your mobile device.

Which is out of bounds for most user-based devices.

Like I'm sure a bunch of people in this room have YUBI keys probably on them right now but see some nodding.

But it's, not really applicable to your general user.

The other thing is that this product, private key pairing is, tied to that device.

Either the authenticator key or if you're on the using an authe a device-based authenticator like your touch ID or face ID on your, or on your phone.

It's tied specifically to that device.

And so you can't use, you can't replace a password with this because it just means you have to register every single device every single time.

That's very annoying.

So you have to move it around in order to use it or add more.

But on the security side of things, it's a very good second factor.

Public and private key cryptography means things are unleakable.

You can never get that private key and you are only sharing the public key.

And it doesn't, nobody else can do anything with that public key, which is wonderful.

And it can't really be phished either.

This only happens on the website that the relaying party as we saw back here this, website here can only happen there.

The, key is tied to that as well.

So I've talked a lot about passwords.

Sorry about that.

What about Passwordless?

How are we doing with that?

Like we felt like we were probably getting close to it with Web authentication and we are.

But I'll take a little diversion through Magic links.

I don't like them.

I don't not like them because of the security.

The security.

I think it's pretty good.

I'm not gonna spend too much time talking about this.

The security on Magic links is pretty good, but sending somebody an email in order to help them log into your site.

I'm trying to reduce friction here, not trust the internet to deliver a thing that is horrible to get from one place to another successfully.

I don't like it.

I don't like having to go to another application to wait and find out if that email has come through.

I just don't like them, but they're pretty secure.

I like that.

I like that.

It's cool.

It's just friction.

It's full of friction.

So we'll move on.

Passkeys.

Here we are.

The future is actually now the present.

We have passkeys.

I will note passkeys are the user facing term for this.

If you're talking to your users, and if Apple and Google are talking to the users, which they are they're calling these things passkeys.

It turns out it's the credential management API [audience laughs].

But in this case, we have multi-device credentials.

So if you are trying to Google for how to actually, or trying to search for how to actually use passkeys as a developer, you actually want to look for how to use multi-device credentials because passkeys just give you the user facing documentation and that it's unhelpful.

So multi-device credentials are Web authentication again, but tied solely to the platform authenticator.

So in this case, it is a touch ID on a laptop face id, on a, on an iPhone Windows Hello whatever Android does.

I'm not a big user there.

but it's Web authentication on that platform authenticator.

So it doesn't use a YUBI key, it doesn't use a third third party device.

It is the platform itself.

And what it does is a passkey is actually a very clever little thing because it's it requires that user interaction with the sort of biometric technology on your device, but that biometric never leaves the device.

So it verifies that the user is who they say they are because they have authenticated with their device before.

So a, second person can't come up and use my laptop to log into my application using my touch id.

So the user is verified on the device and then using the same mechanism that Web authentication does as a second factor we talked about earlier, will then authenticate the user with the Server.

And so we have our user ID and we have an authentication.

And the entire thing proves that a user is who they are with a single touch or look at a device, glorious.

And then we talk about it as multi-device credentials because they then use the platform they're on to sync to the rest of their platforms, which is wonderful.

So you log in on your laptop and if your phone or other device is the same operating system family, then you can immediately, or not immediately, after it's synced you can log on from that device as well.

But the writers of the spec and the writers of this API thought about this and there are cross-device ways to share this as well and log in on one application using an au a pass key that's on a different device, and I'll show you that in just a second.

This is a nonsense bit of code, but because because these because this is all Web authentication based, you can't just look for the existence of Web authentication and public key credential objects.

You actually have to check two things.

Firstly, whether a user verifying platform authenticator is available.

That is we have an authenticator on the platform that will check a biometric and, tell you who that person is.

And secondly, is conditional mediation available?

Can we ensure that this is going to check that?

If both of those are correct and we have public key credentials we can do this, which is cool.

It's nonsense though.

It's, terrible.

And so this actually looks very much the same as creating a public key credential for regular WebAuthn.

But the important thing is the authenticator selection at the bottom in which you have to say the authenticator attachment is the platform.

It has to be the device itself.

Not a a, YUBI key or something.

We require resident key.

Resident key is actually a holdover from the first version of what they called this, but they never changed the name.

That just means this is a multi-device credential.

That means it can go to other devices.

And we ask for preferred userVerification.

We actually want the browser to verify that it is that user.

So I wanna show you this in action.

I'm gonna show you in three different browsers.

So hopefully this works if we can get there.

Here I am in.

Oops.

Safari, let's say Safari.

So this is a nice little demo online, passkeys.io.

And I'm just gonna sign up here using an email address.

Phil Nash at plus Web Directions at gmail.

Yeah, sure.

Doesn't actually need my email address, but this is gonna be my user id.

So I'm signing up and I'm gonna say there is, okay, it says there's no account for this, but do you wanna create new account?

Yes, I'll sign up.

Let's set up a passkey.

This is gonna trigger the browser's Chrome and and, it's asking me to confirm with my touch ID in this particular case.

So I will do, and that's all it takes to create myself a passkey public, private key pair that can then be used to log in.

So this was Safari on my Mac.

What I should then be able to do is go to passkey io on my iPhone.

And choose to sign in.

Now, I've done this a couple of times, so it's gonna gimme a couple of options.

But what we can see is the bottom one is Phil Nash at Web Directions.

So that has already synced across to my iPhone.

I'm gonna choose that one, sign in, it's gonna ask my face id.

And now I'm signed in.

Lovely.

That's cool.

So let's check out the third demo, which is bringing Brave into the situation.

So this is a browser that cannot sync because it's not part of the platform.

It's not synced that passkey across.

But I still wanna sign in with my passkey.

Now I have also signed in with a passkey on this browser as well.

So it's gonna offer me that after I fingerprint it.

But if I go back here, I can actually say I'd like to use a phone with a QR code.

And so this browser has now given me a QR code, which if we look to the, mobile device, I can go scan and it's given me the option to sign in with a passkey here.

And it's gonna give me my three options of passkeys again, but I'm gonna pick the Web Directions one, cuz that's what I just did.

If we sign in face ID on this device, it's gonna share the successful se successful challenge back to the original thing.

And we are logged in, Brave using my Safari browser on my iPhone now.

And if you are then developing this, you probably want to offer.

The, user to add this as a new device a new set of credentials.

And so this is entirely built into the process that it syncs when you can, when it's across the same platform.

And that will work on, your Mac devices.

That will work for Android and ChromeOS as pairing there, or we don't have WindowsPhone devices anymore, do we?

Anyway, it will work across all your Windows machines.

But when you can't sync it like that, we can then use this QR code method, which actually has a lot more security built into it.

For the user, it looks real simple.

But the both devices have to have their Bluetooth and internet connection on in order to fully share this across them.

But but it's there built into the platform that we can use a device to share, to, to log in.

So if we can always convince our users to get their mobile device as their kind of base passkey they'll be able to log in wherever they are, whenever they want to.

So overall the experience is brilliant.

We don't need a password.

We just need to do whatever we do with a fingerprint or a face in order to log into things.

It does, of course require our devices to have a platform authenticator, which of course not everybody does have.

And the syncing is a magical experience.

Like I'm on conference wifi and it was there when I got there.

The security side of it is phishing resistant.

It's, very hard to phish a password that is a private key that is secured inside of your device.

It's unleakable.

You can share that public key with anyone.

It doesn't matter.

The private key is never leaving the device aside from syncing via your account.

It might be perfect.

I'm not a security professional, so I'm allowed to put words like perfect onto a slide.

But if I was, I probably wouldn't.

It might be the ideal thing.

It removes password.

It effectively has two factors because we have both the user verification and also an unknowable secret.

But it doesn't require any more work from users and just a bit more work from us.

There are a couple of the drawbacks, of course support is coming into browsers.

This this, demo here only worked in Safari in the absolute latest version 16.1.

It didn't come out in 16.

We had to wait for a little bit.

But it is progressively enhanceable.

It's absolutely, as Tom said in the last talk, we can progressively enhance this thing.

So the support is coming and we can offer this to our users to give them a better experience and better security at the same time when they have the devices that are available to it.

So as I finish up, we have just some recommendations here for what to do with this, and hopefully you're excited to replace your username and password login flow with passkeys for the future.

The idea should be to detect that support for passkeys first.

If somebody is registering, give them that option to register as a passkey user first.

Although you probably still have to, like I said, browser support is still rolling out.

Platform Authenticator support is not necessarily everywhere.

You can fall back to a to to a username and password, two factor authentication flow.

You do need to support multiple pass keys.

That is another thing.

This normally with a user and a password you probably only need to store one password, one hashed password against the user, but with pass keys, because there is this lightly awkward, if you are an Android user and a Mac user, you probably, you need two passkeys in order to make both devices happy.

So support multiple passkeys.

With fallback to that password with two factor authentication.

Use all the other APIs I talked about to make that a better experience.

And and then once a user can use their passkeys, just upgrade them to that and remove those old weak credentials.

Let's, we don't.

As long as they have that ability to, log in, that one place, the browsers are catching up all the time.

And we can remove passwords, we can remove basically an attack vector and, make again, better experience and better security for everyone.

There's a bunch of links.

I will share these slides later.

I'll tweet them out.

I will masterdon toot them out later.

But these are good things.

Actually I was on passkey dot io go check that out as the, as a very good demo of seeing how they work in action.

Other than that's all I've got for you.

Again, my name's Phil Nash.

I am an amateur developer evangelist, and I'd be very delighted to talk to you more about getting rid of passwords in the future, either online or out for the rest of the conference.