00:00:12.240
Hello everyone! How’s everyone doing? I’m happy to be the first speaker after the keynote. Today, I’m here to share my vision of a world where you don’t have to use passwords anymore. Can you hear me okay?
00:00:26.220
Now, you might think that someone who works in identity and access management would know a lot about passwords and how to deal with them. But I want to tell you about one of the many stories I’ve had related to passwords, and I'm pretty sure many of you have dealt with this as well. It's one of those situations where you wish you didn’t have to rely on your memory for something as simple as paying with your credit card.
00:00:39.540
A few months ago, I found myself in a furniture shop at the checkout. I wanted to pay with my credit card using the contactless payment option. Usually, it doesn’t ask for a PIN, but of course, this time it did.
00:00:52.320
I didn’t remember my PIN, so I thought, ‘Okay, let me check my bank’s application to find my PIN.’ I opened the app and usually sign in with my fingerprint, but this time, it required my password, which I also didn’t remember. Here I am at the checkout, starting to sweat because it had already been about ten minutes of me trying to pay.
00:01:05.300
I eventually managed to pay, but not before getting a six-digit code sent to my phone to unlock the app and access my PIN. This isn’t the first time something like this has happened to me. Yes, I use a password manager to store my passwords, but I forgot to save that particular password. The truth is, passwords suck!
00:01:24.900
Does anyone agree with that? Yes, you’re my people! One of the problems with passwords is they rely on your memory. We have to create long passwords, and with everything else we juggle in our minds daily, it’s easy to forget them. Additionally, passwords can be vulnerable and stolen by unauthorized individuals.
00:01:37.440
And passwords can also be reused by unauthorized people. So, hello everyone, I’m Carla, and I work as a Senior Developer Advocate for Okta, which is an identity and access management company. You’d think I would have mastered passwords, but I haven’t. I’ve been working as a software engineer for the past ten years. Sometimes I make YouTube videos; you can find me as Carla Stabile almost everywhere, although some handles were already taken.
00:01:56.700
Before we dive in, I have some disclaimers. First, I might simplify certain concepts to explain them in an easier way. Second, whenever you see a QR code, feel free to scan it. I brought a bunch of resources, and I will also share these slides on my Twitter, or somewhere else.
00:02:10.320
Everything I share here will also be available to you all. Today, I’m going to share my dislike for passwords (I’ve already started that), and then we will go through a list of topics. We will discuss alternatives, specifically two concepts: WebAuthn and passkeys.
00:02:30.300
So, if we don’t use passwords, what’s the alternative? The slide may have given you a spoiler already. The alternative is passwordless authentication.
00:02:46.740
To get a fancier definition, passwordless authentication is any form of authentication that doesn’t require the user to provide a password at login. There are various ways to implement passwordless authentication, such as using a magic link sent to your email or a code sent via SMS to your phone. However, there are many other methods of implementing passwordless authentication.
00:03:03.060
Now, I believe passwordless authentication is superior for several reasons. Firstly, it improves user experience. Users only need to remember their email or phone number—or maybe their username, if we want to get creative.
00:03:15.360
There’s no need to remember complex passwords. On the other hand, I also believe that passwordless authentication is more secure.
00:03:27.120
Passwords can be vulnerable; we often reuse them or share them with others. If you’ve ever used streaming services, you know this is true. Over 90% of web application attacks stem from credential abuse, like stealing passwords. In contrast, passwordless authentication is more secure because it requires a second factor to prove identity.
00:03:40.320
Another reason why passwordless authentication is better is that it reduces the cost of ownership. Managing passwords can be expensive. We often discuss password expiration, password reset policies, hashing, and secure storage—all of which can be complex and stressful. How many of you have had to implement an authentication system for your application? Each time I have to do this, I think, ‘Did I cover everything? Is this secure enough?’ It can be quite stressful.
00:03:56.040
If passwordless authentication is the alternative, how does it work? Before we dive into that, we need to mention authentication factors. There are three main types of authentication factors: knowledge, which is proving who you are using something you know (like a password or answer to a security question); possession, which involves proving your identity with something you own (like a device); and inheritance, which relates to proving your identity through inherent traits, like biometrics.
00:04:18.720
In passwordless authentication, we eliminate the knowledge factor by using either the possession factor or the inheritance factor. For instance, you can authenticate using a device you own or by using your fingerprint.
00:04:36.180
There are various ways to implement these factors. For example, you can send magic links, one-time codes, push notifications, or use authenticator apps. I may have given away part of the answer with this information.
00:04:55.380
When you combine multiple authentication factors, you add another layer of security to the system. Depending on the type of authenticator and factor used, it can increase what is known as the level of assurance.
00:05:08.880
The level of assurance refers to how confident you are that this user is who they claim to be, rather than an attacker or someone attempting to undermine your system. One way to increase that level of assurance is through public key cryptography.
00:05:19.740
I won’t delve deeply into this, but chances are, if you’ve used Git or GitHub, you’ve engaged with public key cryptography, such as via SSH keys. In a nutshell, public key cryptography uses a public key, which is accessible to everyone, and a private key, which only you know.
00:05:38.520
Any information encrypted with your private key can only be decrypted with the corresponding public key and vice versa. We talked about having multiple authentication factors, and public cryptography enhances security. However, we also want this system to be phishing resistant.
00:05:56.700
For a system to be phishing resistant, every party in the authentication process must prove their identity and intent through deliberate action. It sounds fancy, but it means you need to assert or confirm that you wish to authenticate or create new credentials.
00:06:12.180
This is where WebAuthn comes into play. WebAuthn, short for Web Authentication API, is a browser-based API that allows servers to register and authenticate users using public key cryptography instead of a password.
00:06:26.040
This is a W3C recommendation that's been around for a few years. I’m curious to know how many of you have heard of or used WebAuthn? I see a few hands. Are you all from 1Password or something like that?
00:06:45.060
WebAuthn uses public cryptography for registering and authenticating credentials. It can also utilize hardware authenticators, which can look like this.
00:07:01.320
Which of you own one of these? These devices are known as security keys. In the image, you can see several options such as Google’s Titan and Yubikey from Ubiico. This type of device creates and securely stores public and private key pairs for authentication.
00:07:15.720
Besides hardware authenticators, you can also use a platform authenticator like your Mac’s Touch ID.
00:07:25.680
I’ve been talking a lot, and now I want to show you how this all looks in action with a little demo. Fingers crossed that this video works.
00:07:38.040
There’s a video, believe it or not. Okay, here we go...
00:07:52.860
Music is playing as I try to get this video ready to show you more about WebAuthn and how to create a WebAuthn credential.
00:08:05.280
Let’s see if this works; let me pull up the video.
00:08:32.460
Well, I’m trying to show the video, but it seems to be giving me a hard time. Let’s do a refresh... Still not quite working. You know, it’s strange; it worked perfectly during our morning test.
00:08:47.880
But we have the video saved on my device, so I may just pull that up instead.
00:09:18.240
As I find the video… it’s quite the process, isn’t it?
00:09:31.740
Ok, let’s give this another attempt. Hoping for a better result this time.
00:09:49.920
We want to showcase how to create and use a WebAuthn credential.
00:10:02.760
Yay, this is working! So, what I want to show you is how we create a new WebAuthn credential. I’ll be using just the username, no password required.
00:10:16.920
The browser will ask if I want to create a new credential. I’ll click to continue, and then I'm prompted to use my fingerprint with MacBook’s Touch ID.
00:10:29.520
Later on, when I want to authenticate, the process is similar; I’ll go to sign in using the same username.
00:10:42.000
Unlike a password, the browser won’t prompt me to create anything new but will simply ask for my fingerprint instead.
00:10:56.880
This might seem straightforward, but let’s see what happens under the hood during this interaction.
00:11:05.520
To create a new WebAuthn credential, first, the user sends their username to the browser. The browser then forwards this information to the server, called the relying party in this context.
00:11:18.120
The relying party sends a cryptographically random challenge to the client, which the client sends to the authenticator.
00:11:31.680
Before the authenticator processes the information, it requires user interaction; the user must confirm their intent to create a credential by touching the UB key or using Touch ID.
00:11:44.760
Once confirmed, the authenticator generates the key pair and sends that information back to the browser, signing the challenge with the created key pairs.
00:12:01.440
We send back the signed challenge, the public key, and a private key ID. Note that the private key never leaves the authenticator; we’re only sending an identification that we can use later.
00:12:16.440
The client then sends this back to the relying party, which can store the public key and private key ID.
00:12:30.000
When you want to log in again, the user sends their username to the browser, which forwards that to the relying party. The relying party recognizes an existing user and sends back a new challenge to be signed.
00:12:43.740
The private key ID is essential because it verifies that the signed challenge originates from the same key used for the initial credential creation.
00:12:56.340
Once again, user interaction is required to confirm that they want to sign the challenge using their UB key or MacBook’s Touch ID.
00:13:10.860
The signed challenge, public key, and a public key, are sent back to the relying party for verification.
00:13:25.380
This highlights what happens behind the scenes; the communication between the client and the authenticator occurs through a protocol called the Client to Authenticator Protocol (CTAP2).
00:13:39.480
The interaction between the client and the relying party involves the WebAuthn standard. These two components make up what is known as FIDO2, developed by the FIDO Alliance.
00:13:56.520
FIDO2 aims to eliminate the need for passwords entirely. For further learning, you can scan the QR code provided.
00:14:09.480
Now, having discussed WebAuthn, let’s focus on the methods available. The two main methods are navigator.credentials.create and navigator.credentials.get.
00:14:24.720
The create method assists in generating those public key credentials, while the get method is used for authentication later.
00:14:41.760
As a browser-based API, it is exposed through JavaScript. Fortunately, there is also a gem for Ruby on Rails applications that allows them to operate as a WebAuthn relying party.
00:14:58.560
This involves specifying the origin. In my demo, it was localhost with the name WebAuthn Demo.
00:15:13.920
We set up the options for the registration method, which prepares the payload to send to the WebAuthn API.
00:15:28.920
The payload includes user information such as the username, an ID generated by the WebAuthn gem, and a selection of authenticators.
00:15:45.660
By verifying user interaction, we can stipulate whether the authentication is required, meaning you cannot use a device like a UB key without user verification.
00:16:05.400
As you are building your application, your front-end code will also need to call the WebAuthn API.
00:16:21.480
You will call navigator.credentials.create with the appropriate parameters, including sending along the challenge.
00:16:37.740
Here we send necessary information like the user’s details, keeping in mind that this challenge is a randomly generated value.
00:16:52.680
The browser will assist in guiding users through authenticating with their fingerprint or other means, and you’ll receive a response containing the public data necessary for storage.
00:17:08.640
Once it's time to authenticate with a WebAuthn credential, you will again fetch the user from the database, initializing a call using the get method.
00:17:22.020
You would be using a reference to the WebAuthn generate user ID from the registration process and providing relevant challenges.
00:17:37.620
As for the front-end, again, the call structures will resemble one another closely. You need to ensure you retrieve a challenge from the server side.
00:17:54.720
Also, allow user authentication through various transport mechanisms like USB, Bluetooth, or NFC.
00:18:09.720
I genuinely believe WebAuthn surpasses passwords, primarily because it employs public/private key-based authentication, rendering the private key securely within the authenticator.
00:18:23.820
Moreover, its options ensure user interaction throughout the authentication process, meaning no stored credentials can be breached.
00:18:36.840
WebAuthn simplifies the overall storage protocol — you only store public information in your databases, facilitating a better user experience, and most importantly, there are no more passwords.
00:18:55.920
Now, reflecting back on the agenda, I’ve expressed my dislike for passwords, discussed alternatives, including passwordless and WebAuthn.
00:19:09.540
However, we can look to the future: Is there a way we can eliminate the need to even remember if we created an account for a website?
00:19:25.920
Yes, there’s a solution, and it’s known as passkeys. How many of you have heard about passkeys? Yes, a few of you.
00:19:44.520
Passkeys are designed to replace traditional passwords, and they are intuitive because there’s nothing for you to memorize; your authentication is straightforward.
00:20:00.240
They’re automatically unique for each server, preventing reuse, and they are resistant to breaches, as only public data is stored.
00:20:16.680
Furthermore, they are also inherently phishing-resistant due to their reliance on public/private key cryptography.
00:20:35.520
More technically, passkeys are FIDO2 discoverable credentials, which means they utilize the WebAuthn standard under the hood.
00:20:52.500
While WebAuthn credentials aren’t technically considered passkeys unless they are discoverable, discoverable credentials allow the relying party or server to automatically recognize a username.
00:21:06.480
You might be curious; why shouldn’t we just stick with discoverable credentials? The short answer lies in compatibility. Passkeys are quite new—only gaining popularity in June last year—so some authenticators still don’t support these features.
00:21:24.780
As for passkeys themselves, there are two forms: sync passkeys and device-bound passkeys. Sync passkeys utilize cloud-based systems (like iCloud) to operate across devices, while device-bound passkeys are linked to a single device, such as a YubiKey.
00:21:41.200
One notable feature regarding sync passkeys is their automatic syncing across all devices. For example, if you create a passkey on your Mac, and sync it via iCloud, you can use it on other devices.
00:22:00.200
Let me show you how this looks in a video demonstrating Okta’s implementation of passkeys —currently in early access.
00:22:18.200
So, let's click on login. Apologies if this appears too small; here we have a login form for a system that previously required a password.
00:22:35.860
Upon entry of my email, it prompts me for a password, but instead I click to create a passkey.
00:22:49.680
Using my fingerprint with Touch ID, I can log in. The process is quite seamless!
00:23:05.480
Later, I can log in again using the passkey seamlessly, with the system auto-filling my email. I simply use my fingerprint to authenticate.
00:23:18.680
As mentioned, passwords and passkeys can coexist during the transitional period as we adapt to this new security method.
00:23:34.680
The exciting Multi-Device feature allows syncing passkeys through the cloud, meaning they are available across devices, like a phone login.
00:23:50.800
So, I can authenticate using my passkey across devices seamlessly. You’ll notice I consistently used fingerprint authentication, but I can easily switch to using face identification.
00:24:05.380
This flexibility is important as we shift from relying on passwords towards embracing passkeys.
00:24:20.520
As a recap, I’ve expressed my dislike for passwords extensively. We talked about alternatives and the benefits of WebAuthn.
00:24:35.760
Finally, we discussed passkeys and their advantages for streamlining this evolving area.
00:24:50.320
So what can you do with this information? You can gain early access to the passkey technology within applications that rely on it.
00:25:06.080
Well-known services like Google, Apple, and GitHub are already supporting passkeys, and I’ve personally created a new passkey for GitHub recently.
00:25:20.120
Additionally, I recommend checking out the website webauthn.me to view interactive examples of how WebAuthn flows work along with debugging capabilities.
00:25:32.520
Passkeys.dev is another great resource to learn about passkeys since it’s hosted by the FIDO Alliance.
00:25:44.680
I encourage you to try the implementation at Okta as well. Despite the technical hiccups, it’s been an informative session.
00:26:01.440
Most importantly, we've shared this knowledge without relying on passwords at all. Thank you for your attention, and enjoy the rest of the conference!
