The State of Passwordless Auth on the Web

Ah, what's up, everybody? We're on screen. Yes. Hi. Um, let's get rid of passwords. Whoo! As we already, we just went through, I work at Sona, I'm a developer advocate there. We have a little stand out there, so come say hi to us. The rest of the team's actually sat right there. It's a little way. My name's Phil Nash, I am a developer advocate there. You can find me online in all the places under the name Phil Nash, Twitter, Mastodon, LinkedIn, just come find me, ask me questions. I'd love to hear from all of you.

So, let's get into it. Because we, most people in the world have applications in which they need to log in, hide something around behind an authentication part, and for the most part, we have been authenticating people using passwords, and passwords are genuinely terrible. I hope you agree, I hope that's why you're sitting here. But I will go through a couple of things just to make sure we all agree with this.

Back in 2018, Google ran a survey where they asked a number of questions about account security, where they said things like, how often do you reuse passwords? And this pie chart shows that 52% of people answered they reuse passwords some of the time. Now, that's not a great start. And of course, there is a nice green section here where 35% of people said they never reuse passwords. I like those people. I'm a fan of those people. I count myself among them now. What we have to worry about, well, we do have to worry about the some of the time people. We really have to worry about the 13% of people that when asked if they reuse passwords said they do all of the time. These are the people with one password, not the application but the one string in their mind. And this is terrifying, right? This password, they're normally not good passwords either. They're easy to break, easy to hack, and that's not a good thing.

Also, during the survey, they asked whether people use a password manager. And 24% of people said yes, they do use a password manager. That's cool. They're probably inside that pie chart piece of pie that said they don't reuse passwords ever. Well, that does worry me because 35% of people said they didn't reuse passwords ever. And 24% use a password manager. There's like 11% there who are lying? I guess? You don't have to tell the truth to surveys. But anyway. So, 24% of people do use a password manager. But that means three quarters of people don't. Bad times.

And then, of course, people who are using their passwords are, of course, using all of our favorite passwords. This is the top 10 passwords from NordPass. Password winning in 2022. Well done, password.

Sorry, 123456 and your very close friend, 123456789. I feel like people who only get to six are just a bit lazy. I don't know. If you have used a good password, but you are repeating it, then there's probably an application out there somewhere that has been breached and shared that password with the rest of the world. If you don't know, you should go there now and check out how many of your accounts have been breached and how many of your passwords are out there, and that will make you think about it and change your passwords fairly quickly.

Passwords are terrible. In account security like this, we're surrounded by a bunch of tradeoffs. In security, we want to make sure people aren't breaking into other people's accounts, but we also want to make sure people can indeed log in and get on and do the thing they intended to get to their application to do. Whatever you built for them that they're trying to get through a login form to actually achieve. And so those tradeoffs kind of go between user experience and security. And that's the kind of lens I'm going to look at the solutions we have for the rest of the talk now.

So passwords on the user experience side of things are bad. It's hard to remember good passwords. It's hard to come up with good passwords on your own, at least. And really, you need a password manager in order to achieve this any kind of security using passwords. And then on the security side of things, we already know that's a bad thing, too. It doesn't work either way. It's easy to break passwords like 1, 2, 3, 4, 5, 6, because you can just try that against somebody's account. And if it works, you're in. But then when passwords get leaked, it's easy for attackers to take those leaks and apply them to other applications and see if that will log them in. And they don't have to break into all the accounts. They just have to break into some of them in order to win. And finally, I haven't even mentioned phishing yet, but passwords are very vulnerable to phishing. I always like that phishing websites always tend to look terrible. And I'm pretty sure everybody in this room could build a really good-looking phishing website. Don't. Like, that's not the takeaway from this. Do not try and steal people's passwords. But we could do it. The first answer is to use a password manager.

That allows us to improve the experience. We no longer have to think about our passwords and we don't have to repeat them. It's all stored for us. We never have to know our passwords ever again. Cool.

And then that actually helps the security. We now have long difficult passwords which are unique to each site, although still a little vulnerable to phishing if you want to copy and paste it into another form. But this is very much on the user side of things, right? This is not something we as developers with our applications can enforce upon people. And as we already found out not enough people use them. So we have to do better than that. We have to take further steps.

Now, there are things that we can improve and we can do with our applications, a little bit of HTML, a little bit of JavaScript, in order to encourage people to do things a bit better. I'm going to start that with the autocomplete attribute, my absolute favorite attribute on the element. If you use the autocomplete attribute new password on an input element with type password, browsers will normally suggest a strong generated password for people. It's a great nudge. It's a great way to encourage people to be more secure. It doesn't stop them from writing 1-2-3-4-5-6 in that field, but it does encourage them to do better. If you use the autocomplete attribute on login forms, you can use things like the username, that's just heuristic to the browser to properly autofill this in, and then autocomplete's current password means that you can use that to use the existing passwords that have been saved. New password and current password are particularly useful on those pages where you're changing a password and you don't want to autocomplete the same one into all three boxes. You want the one old password and then two new passwords. It helps.

And then on the JavaScript side of things, we have the credential management API. This is actually an API that's been around for quite a while, and I don't think it's got as much love as it needs to. And that's why I'm here to actually big up the credential management API. It's the most exciting sounding one, right? Credential. Yes. Exactly. Credential management API allows us to store and retrieve credentials in the browser. In this particular case, we're talking about passwords. It allows us to store and retrieve password credentials using the browser's password manager.

And if you have access to the credential management API, we can check for the existence of the password credential in the window object. And if we have that, we can create a new password credential using what we know is a correct username, ID, and password. So, you do this at registration or at successful login. And once you've done that, you can ask the browser to store this credential. And then when and this is gonna pop permissions to the user. In fact, it's actually very recognizable permissions to the user. Because it's the same kind of thing that the browser will already offer. Do you want us to say this password?

It's still gonna cause permissions, but it allows us to get the data that we've stored in the browser and then use it to log in immediately. And so, this looks like I've got some screenshots from nope, nope. You also do it silently. So, if a person hasn't logged out, but you want to just push them through the login flow, you can do it silently using the option unmediated true. I'm not entirely sure I'm a fan of this, but it's there just in case.

And browser Chrome will show a person they are being logged in, even if it doesn't actually ask them for permission. But when somebody logs out and you don't want that to be able to happen, you should call yeah, prevent silent access on the logout so that it's not going to immediately sign them back in again on the next page load.

So, the experience of this looks like this on Android. In this case, it's the browser Chrome saying, Hey, do you want to save this password? And notably for Google they will store it in your Google account rather than just on your device, in your browser. So, this is syncing across things. So, if somebody does this on their mobile device and then goes to log in on their desktop device sometime later, it will be available for them, which I think is cool. When you come back to log in, excuse the odd domain name here, but when you come back to a log in, this is the permissions dialog that says, Hey, we've got some credentials for you. Do you want to sign in. So, this is stuff you should only store on a device you're using. Don't do this on a library computer or your friend's computer because then they'll be back logged in as you next time. But it does allow you to make sign in with a password one click. So, that's it. I'm trying to improve the experience here. We've added a bunch of stuff with this to encourage the experience of logging in to be better.

Better experience. When the browser is looking after this, it's no longer need to remember passwords. We're effectively increasing the number of people using a password manager. Sadly, on the security side of things, it doesn't make people use a secure password. It doesn't make people use a unique password. And so, we have all the issues that we previously had in terms of security. Like I said, passwords are terrible. This is trying to increase the experience of it. So, let's move on. To help the security side of things, we bring in two-factor authentication. You have probably seen a text message looking like this that says, hey, here's your code.

You have probably seen a text message looking like this that says, hey, here's your code. Use this to log in to the site. When you've seen this text message, it's because you've had to go dig around, find your phone wherever you left it because you tried to log in to something and it told you you've now got to go and then I get those messages, I get the thing saying two-factor authentication, then I scroll Twitter for a while on my phone and then I forget what I was doing and the message is timed out. So the experience, sadly, in this case, has regressed. If we look at the experience, we now have two steps. We need another device. We maybe need phone signal. We can do this by our authenticator apps, as well, but still, we're looking at a different device. And so, our experience has regressed, but the security has improved. So this is better for more important accounts. This overcomes the poor and leaked password scenario because using a second device, something you own in order to authenticate you means that it is much, much harder for an attacker to just, you know, replay a set of leaked credentials. It's still vulnerable to phishing. If you can build a site that asks for somebody's username and password, you can build a site that asks for somebody's username and password and then a six digit code. And if you're using SMS for this, there are targeted SMS attacks. I don't have time to go into that right now, but come and ask me how broken the SMS system is later if you're interested.

But can we make it better? Can we improve the security? Can we make the user experience better on this kind of thing? Thankfully the answer's yes, I wouldn't be here if we weren't doing that.

First up we're going to go back to the autocomplete attribute. The autocomplete with the property one-time code will on Safari offer up a six digit code out of a text message in the autocomplete of the browser's keyboard. This looks, I have video for this, this looks kind of nice, I think. In which you go log in, the text message gets sent, and the text gets sent, pop the keyboard up, and there is the code right there in the middle, ready to be input, all you had to do to get that was add an attribute to the element. What's really nice about this is if you are very much dug into the Apple ecosystem and you're using Safari on the Mac and you have messages coming through on your Mac as well, then it works in Safari on Mac as well. You can enter your password there and it will offer that autocomplete in the browser on the desktop. Kind of a magical interaction, and suddenly you don't have to get your phone out, it's already appeared on your desktop. I think that's very cool. And it only takes an attribute to do so.

However, that's only Safari and only Apple. So we have to look to the web OTP API in order to help us out on other browsers. The web OTP API is the credential management API in disguise. I told you earlier this is just a love letter to the credential management API and you're stuck with me now. The credential management API in this case, we don't need to store credentials, but we can retrieve them. And so you do have to make some changes to a text message that you send. In this case, you have to add a final line, which has an app symbol and the domain name you're on, and then a hash and then the code. That app's domain allows the browser to only look at messages that have that domain in if you're on the domain. That's a phishing protection there. We're not going to autocomplete this into a website that you didn't sign into. Once you've done that, we ask the credentials API to get, in this case, the OTP credential using the transport SMS. You can pass an array to transport there, but the only item that goes in that array right now is the string SMS. It's a single item array. But I like that because it does give the idea that we're trying to this could be extensible. This is something we could have an authenticator app do as well. When we do that, it pops a permissions dialogue to the user to say, hey, do you want to allow the browser to use this text message? And when you get it back, you get back an OTP object with a code property that you can use in your form. This looks like this when you do it. And it gets a little bit crazy because you see on our Android device, you get both the incoming text message and the permissions dialogue at the same time. But hopefully the permissions dialogue at the bottom of the screen takes the attention and you see there it says, do you want to allow Chrome to read the message and use this code? If you press allow, the JavaScript gets that code back, you can fill in the form and carry on.

So, two-factor authentication was a regression in user experience, but if we're able to add these autocomplete attributes, we turn it into a minimal step, normally hitting an approve or hitting an autocomplete.

That makes it a lot quicker. We don't have to go digging for our devices. It's just done. It still requires the other device, still requires an authenticator app or text message and maybe a phone signal for that kind of thing. But it's a better experience now that we've added this autocompletion.

On the security side of things, we haven't changed that, it overcomes the password problem, it's less vulnerable to phishing, especially if we use the Web OTP API that is targeting it specifically to the domain you should be logging into. It doesn't fix the SMS system, though.

Then we move to security keys. You probably have a security key, especially if you have a work one, particularly if you're dealing with your work stuff, security keys are wonderful, and we can use them in the browser using the Web Authentication API. Of course Web Authentication is really just a credential management API, it's navigator credentials, it's the same thing, like I said, I love it.

In this particular case, Web Authentication API allows us to use the browser to create and store a public and private key pair, we then share the public key back to the site that you're trying to log into or register with, and that, the site can then use the public key to verify things signed using the private key. This is how we create it, we use navigator credentials create, and in this case, the server sends a challenge, a set of random bytes which we go and create, which we send in to the creation, we also have to say which domain we're on, this ties the public and private key pair to that domain specifically so it is not possible to fish a security key using real authentication. Then we put some user details and some algorithms that we can use, and this is going to set up a whole set of cryptography stuff, it's going to sign that challenge and return us both a signed challenge and the public key, which we can share back to the server, the server can then use the public key to verify the challenge and assign this key to this user.

Then when we go back to log in, as our second factor in this case, we can use navigator potentials, get with the public key, send in another challenge, and then in this case it's just going to return the signed challenge, we don't need to return the key again, it just returns a challenge that you can send back to the server, decrypt and verify using the public key, and you're through. This is really cool, because now we have this authenticator key that's acting as our two-factor authentication, it's plugged into our machine and we can, and it's just a touch normally to interact with it, so we're back to two steps, but it doesn't need an authenticator key.

This is not great for consumer kind of stuff, because we cannot expect every consumer to own a private, to own a security key. And it's tied to the key itself, so if you are logging into another device, you need to move the key to that device or register multiple keys. So, a bit of an upfront issue there, but on the security side of things, we're now in the world of public and private key cryptography. If that public key is given away in some kind of breach of the service, there's not a problem, it's a public key. All it can be used for is verifying something from the private key, so we can't leak this and it can't be phished either. As we said, we've tied the key to the domain. This isn't great. This is great. Wonderful. We have this. The only difficulty here is needing the keys themselves.

So, that's where we're getting to in this world where we're trying to remove passwords entirely. And finally, we are at that point. This has been a lot of work. I think between browsers and organizations that work on this security stuff.

And we got to passwordless which is passkey. This is what you see Google and Apple talk about when they introduce this to their users. Passkeys are multi-device credentials. Yes, still the credential management API. It doesn't go away. But actually, passkeys are, in fact, just web authentication under the hood with a couple of tweaks that mean we can drop the password at the start of our system.

Passkeys is web authentication but it uses a platform authenticator. What I mean by that is on my Mac here, that's the fingerprint touchpad. On my phone, it's face ID and you will probably have various devices that have different ways of verifying biometrically like that. It is a biometric verification but those biometrics are never shared to the server. Your user biometrics remain safe. This is a good thing. Some people wanted to implement user biometrics as a two-factor authentication idea which is a bad idea because if those get leaked, it's real hard to change your fingerprints. But using our platform authenticator, the platform itself verifies that the user is who they say they the device. We get the step sorted before we send any data to the server, which is cool. And then once it's verified, it returns a signed challenge which we send to the server and authenticate. This is almost as a two-factor authentication because we have biometrics plus something we know, our public private key pair. And it also syncs across devices. This is the most important thing, really, for the user experience side of things. Our web authentication using an authenticator key meant we would have to move keys around or register multiple things. But pass keys are able to sync across devices. This is dependent on the platform. If you are on Apple hardware, keychain with iCloud will sync these keys across your devices. And then if you're on Google hardware, if you're on Chrome OS or Android, that's going to work, too. But there's some difficulty there in that if you use different browsers in different places or if you have an Android device and a Mac laptop, that's not going to sync. So they built into this system a way to use a pass key across device in order to allow you to log in even if you haven't saved a pass key for that device yet. So this is a good experience. We're going to see it in just a second. First, I want to show a little bit of code. Like I said, it's web authentication with a couple of extra tweaks.

And so you have to test for the existence of those tweaks. And this is a little concerning. I feel like the standards committee here was probably a Java developer at some point, as we have to ask for things like is user verifying platform authenticator available? Look, it's a very wordy function name. But at least you know what it's doing. Actually, I say that, but is conditional mediation available is not quite as obvious. But is user verifying platform authenticator available is a function that we can call to find out whether there is a device, an authenticator on the device so we can ask is conditional mediation available allows us to show options of passkeys that you have registered with the device. If those two things are available, then we can go on and call on web authentication. So, this again, credential management API. When we create a credential in this case, we have to ask for a couple of extra things. In this case, it's the authenticator selection part at the bottom. And we have to say we want the authenticator attachment to be platform. This ties it to the device. It doesn't allow you to use a key for it. Now, I've done some tests on some people recently who are like, I still want to use my key, though. And it turns out you can implement it with a key as well, with a security key. But we're trying to do this for regular users who don't have security keys but do know how to put their finger on their laptop. And then the other side of things is require resident key that allows the key to be saved to the device and retrieved later. So if we have those two things, we get a pass key out of this as long as the user says yes.

And this is what it looks like. I've gone to passkeys.io because it's a really good demo of this, and I'm in Safari on the desktop on the left-hand side of the screen at this point. We don't have an account for it, so we're going to create one and make a passkey. This has popped that permissions dialog. You have to hit the fingerprint reader and save it, and that's saved ourselves a passkey. Good stuff. And so it's not very exciting beyond the login in this particular demo, but that's what it does. You can go back then to log in and say, now I want to log in with the passkey. I did this demo a few times, and you can't yet delete passkeys, but it's the one at the bottom there with my Sonosource email that we're looking for. So I wasted enough time there to make sure that it synced across to my iPhone, which is now on the right-hand side of the screen. And so if we go to the phone, we can go and immediately just sign in with a passkey. And again, we're going to get that long list of passkeys that I've saved, but if we look down the bottom, we find the Sonosource email again.

We use our face ID in this case, and it signs in immediately. You can actually verify that the passkey is the same. It's got the same ID on the screen there. So that's great across browsers on the same network, but if we go to Chrome now, we can go sign in with a passkey, and Chrome knows we don't have any passkeys for this, so it immediately offers us this QR code.

We can then use the phone to scan the QR code. I don't know how to use my phone. Use the phone to scan the QR code, and use it to sign in with a passkey, and it gives us the same options again. One more time, we scroll to the bottom, find the Sonosource email, and say, yeah, I want to do that one, face ID. The passkey succeeds, sends it back to the browser, which can communicate back to the server, and we're logged in in Chrome.

Now, the one thing this particular demo doesn't show is that we should then offer within that browser, like, to register a new key, so you don't have to go through the second device process again. But I think that's pretty slick. I think from a registration and a login point of view, we have fixed almost all of the things. So, the experience is great. We now have no need for a password. We never have to ask people in the future if they reuse their passwords, because you can't reuse this stuff. We don't have to think about long, difficult passwords or different ones for each device, each application, because it's done entirely for us. It does require the platform authenticator. And while most people, not all people, may have a device that is capable of that. And so, we do still have to implement the old stuff, which is why before I get to this passwordless thing, I tell you about how we can improve that stuff along the way. But then it syncs across devices. And, again, that's quite a magical little experience, I think. When you've logged in in one place and you find you can log in on another device without any more effort. Wonderful. And then on the security side of things, it's all the things I said about web authentication earlier on. It's phishing resistant, it's public private key, you can't leak it. It's glorious. I am not a paid professional security consultant in any way, which means I'm allowed to go, is it perfect? Perhaps. But maybe one drawback is that we rely on platforms like Apple and Google to allow us to do this syncing thing. Now, these keys are encrypted by those account passwords before they are shared to the various clouds and only decrypted back on the device. So, it's fairly safe.

But if you're the sort of person that will never put anything into iCloud or into Google's cloud, then you're not going to be happy with this. But, thankfully, those are just paranoid security professionals who don't like doing those kind of things anyway. And this is trying to fix account security and authentication for regular users.

Are there some other drawbacks? Well, of course, there are. There's always browser support. But, thankfully, we're in a position right now where it's supported in Chromium, so across the board kind of Chromium based browsers. It's supported in Safari, as we've seen in the demos. And Firefox is supposedly working on it this year. I can make no promises for the Firefox team to say whether it's supposed to be deployed this year. But fingers crossed, hopefully.

1Password is a funny supporter of passwordless. I feel like they might eventually have to change the name of their company. But they're down for it. They also want to see the end of passwords. And so, while they're actually trying to support it as part of their plugin, part of their application, they're also supporting people who are building it in. And if you go to Passkey's directory, this is a site supported by 1Password. Listing out the places that now support passwordless via Passkeys. And you can go look through this list, pick out accounts that you have, and go login and see if you can register yourself a Passkey and get rid of those passwords. I've done this to my Microsoft account, which is nice. I don't have a password to get to my Microsoft account anymore. I've added it to GitHub. But it's only used as a second factor right now. But hopefully that's something we can change. And there are other places.

So, as some recommendations for this, this is the time to implement this. This is the time to make our accounts, make our account authorization, authentication a better experience and a more secure experience for everyone. So, detect Passkey support and offer it upfront. Support multiple Passkeys. Like I said, we want to be able to offer a Passkey registration if you've had to log in via the QR code method. We still need to build in fallbacks to passwords and include two-factor authentication because passwords are just not enough. But if we use all the tips I went through at the start of the talk, we can make that experience better and slightly more secure as well. And then finally, once a user can use their Passkeys, you can offer for them to remove that password, that insecure credential. I'd be happy to remove it from my Microsoft account and other people can do so too. I have some links in the slide which I will share out on social media. But other than that, let's get rid of passwords. Let's go Passkeys all the way. Again, my name is Phil Nash, I'm a developer advocate for Sona.