The State of Passwordless Auth on the Web

Rate this content

Can we get rid of passwords yet? They make for a poor user experience and users are notoriously bad with them. The advent of WebAuthn has brought a passwordless world closer, but where do we really stand?

In this talk we'll explore the current user experience of WebAuthn and the requirements a user has to fulfill for them to authenticate without a password. We'll also explore the fallbacks and safeguards we can use to make the password experience better and more secure. By the end of the session you'll have a vision for how authentication could look in the future and a blueprint for how to build the best auth experience today.

30 min
05 Jun, 2023


Sign in or register to post your comment.

AI Generated Video Summary

Passwords are terrible and easily hacked, with most people not using password managers. The credential management API and autocomplete attribute can improve user experience and security. Two-factor authentication enhances security but regresses user experience. Passkeys offer a seamless and secure login experience, but browser support may be limited. Recommendations include detecting Passkey support and offering fallbacks to passwords and two-factor authentication.

1. Introduction

Short description:

Let's get rid of passwords. As a developer advocate at Sona, I'm here to answer your questions and share insights. Find me online as Phil Nash on Twitter, Mastodon, and LinkedIn.

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.

2. The Problem with Passwords

Short description:

Passwords are genuinely terrible. 52% of people reuse passwords some of the time, while 13% reuse passwords all the time. These passwords are easy to break and hack. Only 24% of people use a password manager, leaving three quarters of people vulnerable. The top 10 passwords of 2022 are all too common.

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.

3. Trade-offs in Password Security and User Experience

Short description:

Passwords are terrible. They are hard to remember and come up with on your own. A password manager is essential for security. Passwords can be easily broken, especially common ones like 1, 2, 3, 4, 5, 6. Leaked passwords can be used to access other applications. Phishing is a significant vulnerability. The solution is to use a password manager.

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.

4. Improving User Experience and Security

Short description:

We can improve the user experience by eliminating the need to remember passwords. This can be achieved through the use of password managers and the autocomplete attribute in HTML. Additionally, the credential management API allows for the storage and retrieval of password credentials in the browser.

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.

5. Using the Credential Management API

Short description:

With access to the credential management API, we can check for the existence of the password credential and create a new one. This can be done at registration or successful login. The browser can then store the credential, prompting the user for permission. It provides a recognizable experience similar to the browser's password saving feature.

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?

6. Improving Login Experience and Security

Short description:

The browser allows users to log in immediately by using stored data. Silent login is possible if the user hasn't logged out. The browser Chrome shows a person being logged in without asking for permission. The experience on Android involves saving passwords in the user's Google account. The permissions dialog prompts users to sign in with stored credentials. This feature should only be used on personal devices. It improves the login experience but doesn't address password security. Two-factor authentication is introduced for enhanced security.

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.

7. Two-Factor Authentication

Short description:

The experience of using two-factor authentication has regressed in terms of user experience, but it has improved security. It requires an additional device and is vulnerable to phishing attacks. SMS-based authentication is susceptible to targeted attacks. If you're interested, ask me later about the vulnerabilities of the SMS system.

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.

8. Improving Security and User Experience

Short description:

Can we improve security and user experience? Safari's autocomplete attribute offers a six-digit code from a text message. The web OTP API retrieves credentials on other browsers. Add an app symbol and domain to the message for phishing protection. Permissions dialogue allows the browser to use the text message. Two-factor authentication becomes a minimal step with autocomplete attributes.

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.

9. Using Security Keys and the Web Authentication API

Short description:

Adding autocompletion has made the login process quicker and more convenient. On the security side, using security keys and the Web Authentication API provides a strong authentication method. The API allows the creation and storage of a public and private key pair, tied to a specific domain. This eliminates the possibility of phishing a security key. Using the public key, challenges can be signed and verified, providing secure two-factor authentication. However, consumer adoption of security keys may be a challenge, and the keys need to be physically moved between devices.

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.

10. Passwordless Passkeys

Short description:

Passkeys are multi-device credentials that use a platform authenticator, such as a fingerprint touchpad or face ID. Biometric verification is done locally, ensuring user biometrics remain safe. The platform authenticator verifies the user's identity before sending any data to the server. Once verified, a signed challenge is sent to the server for authentication. Passkeys can sync across devices, but there may be difficulties with different browsers or platforms. A pass key can be used across devices even if it hasn't been saved on that specific device. This provides a seamless and secure login experience.

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.

11. Implementing Passkeys

Short description:

To implement passkeys, we need to test for the existence of certain tweaks. We can use the isUserVerifyingPlatformAuthenticatorAvailable function to check for the presence of an authenticator on the device. If conditional mediation is available, we can show options of passkeys registered with the device. By using the credential management API and specifying the authenticator attachment as platform, we can create a passkey tied to the device. The passkey can be saved and retrieved later with the require resident key option. This allows regular users to use passkeys instead of security keys.

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 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.

12. Logging in with Face ID or Passkey

Short description:

We use our face ID or a passkey to sign in immediately, eliminating the need for passwords. The experience is great, with no need to remember or reuse passwords. It syncs across devices and provides a magical login experience. On the security side, it's phishing resistant and uses public-private key encryption. However, it relies on platforms like Apple and Google for syncing.

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.

13. Conclusion and Recommendations

Short description:

There are drawbacks to passwordless authentication, such as browser support. However, it is currently supported in Chromium and Safari, with Firefox working on it. 1Password supports passwordless authentication and maintains a directory of places that support it. Recommendations include detecting Passkey support, offering multiple Passkeys, and including fallbacks to passwords and two-factor authentication. Once users can use Passkeys, they can remove their insecure passwords.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Server-side Auth with Remix, Prisma, and the Web Platform
In this talk, we'll get a live coded demo of building custom hand-rolled authentication. When you have the right tools (and we do), authentication can be quite simple and secure. This is more (and better) than just: "Install this library and you're good to go." When we're done we'll have our own auth code that can evolve with our ever-changing requirements without a need to learn some library-specific APIs. We'll be leveraging the Web Platform the way it was meant to be done to give us simple and secure server-side authentication for the web.
You can check the slides for Kent's talk here as well as demo code.
React Advanced Conference 2021React Advanced Conference 2021
22 min
Let Me Show You How React Applications Get Hacked in the Real-World
Modern frontend frameworks like React are well thought-of in their application security design and that’s great. However, there is still plenty of room for developers to make mistakes and use insecure APIs, vulnerable components, or generally do the wrong thing that turns user input into a Cross-site Scripting vulnerability (XSS). Let me show you how React applications get hacked in the real-world.
JSNation 2023JSNation 2023
22 min
5 Ways You Could Have Hacked Node.js
All languages are or were vulnerable to some kind of threat. I’m part of the Node.js Security team and during the year 2022, we've performed many Security Releases and some of them were really hard to think about.
Did you know you can make money by finding critical vulnerabilities in Node.js? In this talk, I’ll show you 5 ways you can have hacked Node.js and how the Node.js team deals with vulnerabilities.
JSNation Live 2021JSNation Live 2021
9 min
Securing Node.js APIs with Decentralised Identity Tokens
Authentication and Authorization are serious problems. We often dedicate a lot of time to craft powerful APIs but overlook proper security measures. Let's solve it with Magic using a key-based identity solution built on top of DID standard, where users’ identities are self-sovereign leveraging blockchain public-private key pairs. In this talk, we’ll look at proper ways to secure our Node.js APIs with Decentralised Identity Tokens. We’ll go from learning what Decentralised Identity standards are, how the users’ identities are self-sovereign leveraging blockchain public-private key pairs, why they’re the future of API security, and to put theory into practice we will build a real-world implementation using Node.js where I’ll show common best practices.

Workshops on related topic

React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Day Berlin 2023React Day Berlin 2023
127 min
Authentication Beyond Passwords
Passwords have long been the keys to our kingdoms. However, they often become the weak points in our armor — forgotten, misused, or exploited. Our Next apps often make use of passwords to authenticate users, but what would a world with no passwords look like? And how we can start driving into that future today?
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Node Congress 2022Node Congress 2022
155 min
Managing Authentication in Next.js
Next.js is a compelling framework that makes many tasks effortless providing many out-of-the-box solutions. But when it comes to authentication and user security, it's our mission to make it reliable, secure, and efficient. In this workshop, we'll focus on different user authentication and session management approaches, starting from a custom authentication strategy (that we will build together), and ending learning how to identify and integrate the right auth provider (Auth0, Firebase, etc.) for any app.
Table of contents:- A brief introduction to Next.js- Building an authentication mechanism from scratch- Why we should avoid custom authentication- How to identify the proper authentication mechanism and provider- Integrating NextAuth.js, Auth0, Firebase, or any other provider
JSNation 2022JSNation 2022
99 min
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
npm and security, how much do you know about your dependencies?Hack-along, live hacking of a vulnerable Node app, Vulnerabilities from both Open source and written code. Encouraged to download the application and hack along with us.Fixing the issues and an introduction to Snyk with a demo.Open questions.