William Brown is back! This time Josh chats with him about Passkeys. WTF are they? A Passkey is a form of multi factor authentication, but it’s not super obvious what that really means. William does a fantastic job explaining what a Passkey is, how we got to where we are today with Passkeys. He shares a ton of explanations about the whole world of authentication along the way. Some of this stuff is basically magic.

This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.

Episode Transcript

Josh Bressers (00:00) Today, open source security welcomes back William Brown.

William has come to tell us about Passkeys because in all of the time I’ve done research my only question is like what in the fuck is a pass key William?

William Brown (00:12) You know, I’m really glad that you’ve established early on that I’m allowed to swear in this. ⁓ As an Australian, ⁓ what was the joke I saw the other day? It’s like, ⁓ it was the British flag and it said English classic, American flag, English new, and then the Australian flag, English explicit. ⁓ anyway, yeah, yeah, it’s good to be back. I’m happy to talk about podcast, Passkeys of podcasts. I’m here to talk about podcasts.

Josh Bressers (00:15) Yeah, all you want, all you want.

Nice.

Right

on.

William Brown (00:42) yeah, so, ⁓ I’m not gonna say that I am the only person in the world who knows what a Passkey is. ⁓ I would hope that I know a bit more about it than most, having given my background. ⁓ I specialize in identity management. I work for SUSE, though I’m not here under that corporate side today. This is my open source work. And as part of that, I wrote the WebAuthn library for Rust and…

That is one of the key topics that is very intertwined with what is a passkey. So, what have you found confusing about passkeys so far? You’ve said that you find it hard to understand or you found it confusing. So what have you found? Like what’s tripped you up?

Josh Bressers (01:14) Woo!

Okay, so

I will try to explain the kind of universe I sit in right now and you can laugh at me and correct me if you like as we go. It’s fine. I’m perfectly comfortable being laughed at. But so just from a usability perspective, The Passkeys are a couple of years. I feel like about a year ago, everyone was talking about them nonstop. I don’t hear people talking about them all the time anymore. And I suspect that’s because the people who used to talk about Passkeys tried to actually use them and they couldn’t make anything work right.

William Brown (01:31) Mm-hmm. I won’t laugh.

Josh Bressers (01:54) So I have like two use cases I generally see. There’s my phone, which I do it to take a picture of a QR code usually on the screen, right? When it comes to doing passkey logins and things like that. And there’s some magic that happens behind the scenes. I have no idea how that works. And the other one is one password. One password loves trying to tell me that I should use it for passkeys. And I feel like maybe that defeats the purpose of like.

multi-factor authentication. don’t know, that’s maybe another topic. But when I have one password, I did set it up for Discord just to see what it was like. And I just click a little button and like it logs me in magically with a passkey. And I’m like, I don’t know what’s going on here. Like this is bizarre. And I feel like I did some research and I don’t have this all in my brain as well as I would like to, but there’s apparently like multiple, like I don’t know if I call them standards or technologies for passkeys. There’s not like one way to do passkey is my understanding.

William Brown (02:47) Yeah, yeah. So, alright. So, you’ve, I think you’ve really started with a really good, like, foundation here. And part of that confusion I can see is that, you know, as a user you’re seeing all of these different facets of what a passkey is. And part of this is because passkeys are a very evolved thing. Like everything in technology, it evolved from somewhere. Now, now, ⁓ in this, I love referencing NIST.

Josh Bressers (02:53) Okay.

Yeah, yeah.

⁓ sure.

William Brown (03:17) special publication 800-63b I will reference it a few times throughout this because it is a great document and this is where our journey starts. So once upon a time we had passwords and they were bad for a whole bunch of reasons. Well, and that’s the thing is when we look at a password, we have to look at what are the risks associated with a password.

Josh Bressers (03:20) Excellent.

Yeah, and they’re still bad.

William Brown (03:46) Now, there is a really fantastic blog post. ⁓ I believe it was from a Microsoft Azure engineer. And they were discussing in their blog post and said, why your password does not matter. And it was really interesting because what it described was, hey, the attacks on passwords aren’t what you think. Most of the attacks on passwords are things like the password gets disclosed.

through a backend breach or you reuse the password on multiple sites, things like that. in a lot of attacks, the attacker already has your password, right? So things like phishing and all of that. Now, over time, we’ve started to improve upon this with the addition of technologies like HOTP, which was the hardware-based version, and then TOTP, which is the time-based one. But both of them are pretty simple. You have a shared secret, but on both ends, and a rolling counter that does a HMAC

⁓ and you know, you derive a short code out of that that’s only valid for a short period of time. And these help with the issues of your password has been disclosed. Because if you, your password is known, you don’t have the TOTP and you know, vice versa. If maybe you have the TOTP, maybe you don’t have the password. So, but this had its own cons and you could do real time phishing and a whole bunch of other stuff. a, ⁓ I don’t remember who originated the standard.

I want to say it was Yubico, but they created U2F or Universal Second Factor. ⁓ And you might remember this from like the old Yubikeys, like the old ones where if you put it in and there was always the game where if you touch it, it would spit out the long string of characters into your chat by accident. That was original, that that’s Stronger Characters is actually Yubico’s original OTP method, but they went on to do U2F.

Josh Bressers (05:33) Yes. Yes.

William Brown (05:42) And U2F was pretty simple. You’d put in your password and then the website would say, hey touch your authenticator, it would blink, you would touch it and you would be signed in. So what’s going on under the hood when your authenticator is blinking? That’s what is most important to understanding U2F and then following that web-authenticator passkey. So what happens is that when you take your YubiKey and you register it on a site, what the site is doing is it says, hey,

I want you to give me your public key, basically. And the device, like a YubiKey, it will then give back two things. It probably gives back a bit more than two things, but for simplicity’s sake, we’re to say two. It’ll give you back a credential ID and a public key. The credential ID is a unique identifier that allows the key to find that private key again in the future.

Josh Bressers (06:16) Yeah. Yeah.

William Brown (06:42) And the public key is, well, the public car. So when you go to log in, what’s happening is that a challenge is sent to your device with a ⁓ nonce, a one-time randomly generated value that, and the relying party ID or your domain name. And your browser takes those two pieces of information and then sends them via CTAP, or at least in U2F, CTAP1, the client to authenticator protocol one, sends it to the authenticator and

Josh Bressers (06:59) Yes.

William Brown (07:12) ⁓ It’ll blink and what’s happening at that stage is that the credential ID has loaded into the authenticator. It now has the private key available and it says, cool, I’m going to sign this challenge and the relying party ID. But to release that, you have to touch. Only if you touch will the signature be released and performed. The signature comes out and then sent back to the website and it can validate, hey, this signature was created and validated with the public key.

Josh Bressers (07:31) Yeah, yeah.

William Brown (07:42) So that’s awesome. So that’s really where the basis of this whole thing is. We’ve got asymmetric key cryptography, a process where there has to be some kind of human interaction. And the most important one here is the signing over the relying party ID. And that’s what makes it unphishable

And that’s because the relying party ID doesn’t come from the web server, it comes from your browser. Yeah, so your browser says to the authenticator, hey, this is where I believe that I’m looking at, please sign this. So if someone was to try and fish you, you would be signing a challenge over fishing.totallylegit.ru, not my super secure bank.com. ⁓ And so as a result, you could forward that signature and…

Josh Bressers (08:06) Right. Yes.

William Brown (08:30) The relying party at other end will say, no that’s not my RPID, go away. Cool. So that’s how U2F worked, right? Super simple, super easy. You’ve probably used it before, I know a lot of people have, but it never really took off, never became like a huge thing. I know a lot of people in tech were probably using it. ⁓ But there was a bit of a magic trick going on here. And what that magic trick is, is that your key actually doesn’t really have any storage on it. Remember how I said that there’s…

Josh Bressers (08:57) right.

William Brown (08:59) Remember how I said that during that registration you get a credential ID back? That credential ID is what is called a key wrapped key. And a key wrapped key is in your YubiKey there’s actually a master key. So say like an AES 256 key. And that’s all the YubiKey has in it, is that one AES key. When you send that credential ID back into the YubiKey, it decrypts that credential ID and that credential ID

is actually an AES-256 wrapped private key. That is your private key. So this is how those keys had unlimited storage. Because they weren’t storing anything. They relied on the server to store everything for you. That’s the magic trick. And of course, you know, there is an argument of, but you’re just putting your private key out there and it’s encrypted. What happens if this arm brute forces it? Well, one would certainly hope that the AES-256 generator in a YubiKey is secure. And second, if someone could break AES-256,

Josh Bressers (09:40) right. Yes.

William Brown (09:58) You’ve got bigger problems. Now, of course this is like, there could be other keys that may use something like, you know, DES3 because it’s three times more secure than DES, you know, like it’s so good, but ⁓ we’re to assume that your key for some root, for all intents and purposes, actually does the right thing. ⁓

Josh Bressers (09:59) Yeah, yeah.

William Brown (10:20) So that was how U2F worked. So at this point, you seem to be following. I haven’t lost you, haven’t confused you.

Josh Bressers (10:25) No, you

actually talked about this at length last time I talked to you, so I understand this pretty well, thanks to you.

William Brown (10:29) Yeah, cool. Awesome. Yes!

Winning at education. So, U2F was, that was where everything started, right? So then it evolved into WebAuthn. So WebAuthn was kind of the step up. Now, this is where we start to move from your YubiKey as just the single factor credential or single factor authenticator and

Josh Bressers (10:43) Yes.

William Brown (10:57) per NIST single factor cryptographic device per section 5.17. ⁓

⁓ yes, I, I, I am organized for these podcasts and I do have a screen of notes. I, I don’t want to put my, you know, foot in my mouth and say something wrong. So anyway, so WebAuthn came along and it started to shift that bar a little bit higher. And this is where we see the concept of something called passwordless. Pass, yeah. So passwordless is that same flow that we just talked about before, but there’s no password step. The only step is

the interaction with your YubiKey. But we still want this to be multi-factor. And so again, per NIST, this is a multi-factor cryptographic device. So what this would do is you type in your username to the website, it would return your key wrapped key, and your YubiKey at this point would prompt you for some kind of user verification. And that user verification can take a few different forms.

It could be a biometric. I have a YubiKey 5 bio here which has the little fingerprint reader. It could be a pin. It could be that you’ve got like a four digit or an eight digit pin and that’s validated by secure enclave. It has hardware brute force protection so you can’t just like hammer it and try to, you know, brute force the pin. ⁓ It could be, you know, face. It could be blood test. I don’t know. ⁓ Really, the user verification is just…

All it is at the end of the day is within that signed data that we were talking about, we add a few extra flags. We’re not just signing the nonce, the relying party ID now, but we’re some flags about the authenticator. And one of those flags is a Boolean that says, did user verification succeed or not? Yes, no.

Josh Bressers (12:47) Now I remember this because you told me last time a bunch of things like the password managers lie about this one.

William Brown (12:54) Yep, they do. And that is where we get into a ⁓ bit of a side tangent here. But, you know, this concept of passwordless is really good because again, we don’t have a password to get broken. We’ve now got a hardware cryptographic store for your PIN. It can’t be attacked. ⁓ It’s very difficult to attack. But we are putting so much more faith in this device to do the right thing. And as, you know, Josh has correctly remembered, ⁓

There are, you know, again, it’s a boolean flag, like a device could just lie about this. So, as a side tangent, if you are an organization looking to deploy this kind of thing, this is where key attestation is a really important concept, because that’s a cryptographic chain of trust to know that the device was manufactured by a company or an organization that you trust to have done the right thing. And you can validate, yep, this hardware is actually doing the correct thing and not lying to me.

So, this is where things were at with passwordless and you know, this still works with the same key wrapped keys, the same credential ID, unlimited amounts of credentials, all of that jazz. ⁓ You know, you could go to the website and yeah, you just use your YubiKey and that’s it. And we would start, and at that time, you know, there was a bit more interest in certain other types of authenticators, like this is where you start to see things like Windows Hello, which is the TPM.

or the trusted platform module of your PC ⁓ which again is a ⁓ cryptographic processor in your machine which is software hardened to prevent like you know viruses or ⁓ attackers from brute forcing that ⁓ if they get access to your machine. ⁓ We also start to see things like smart cards as a form factor. I actually have a Fido smart card here somewhere on my desk. I won’t show you my desk because it’s horrifying. ⁓

This is nice and clean. This is the junk, right? I’ve been creative about the camera angles here. Correct. I have a beautiful ⁓ example of this when I gave a talk for RustConf actually where it’s like the product versus pack shot and it’s the picture of me against the beautiful white backdrop and like the soft lighting and I’m all well dressed and then you turn it around and my setup is my laptop stacked up on a box on top of a wheelie chair.

Josh Bressers (14:55) It’s the cone of clean we all have from our camera to our background,

William Brown (15:20) with like arm lights and my laundry on a clothes hanger and like some pillows on the ground and just complete chaos just like absolute dumpster fire going on in the background. You know there probably was a pizza box on fire in the lounge room at the time but you you wouldn’t know it from the product shot. Anyway so back to the story so at this point WebAuthn we have passwordless and we start to have different types of devices so you you’ve got your TPMs

Josh Bressers (15:27) Nice.

William Brown (15:47) Phones start to have things like, as you mentioned, ⁓ phones these days, they all have like a secure enclave or a trusted execution environment, you know, and they’ll call it different things. Android tends to be a trusted execution environment, whereas an iPhone, I think, is a secure enclave. ⁓ Some subtle differences in how they work, but all intents and purposes, you have a hardware cryptographic ⁓ processor that is hardened against attacks. ⁓ And so this was…

Really cool, but around this time, you didn’t really see people using this. If you wanted to activate WebAuthn on an iPhone, had to go into Safari, Debug Settings, Android could do it, but it wasn’t really common. ⁓ But at this point in the WebAuthn community, people start to talk about something called username-less. And this is a step on top. So previously what we’ve talked about is you type in your username,

Josh Bressers (16:38) Hmm.

William Brown (16:43) and then the site challenges you with your key wrapped key and then you have to do the user verification and then the signature is released and then you’re logged in. Username list takes this one step further. Username list stops relying on the key wrapped key. Now we actually move that private key and some state into the device. So this includes some stuff like a display name, a display name of the user.

Josh Bressers (17:03) Okay.

William Brown (17:11) a user identifier, hopefully a UUID, something like that that uniquely identifies the user, a display name for the website or service that you’re accessing, things like that. Think about what are the kind of details that you’d have in a password manager. That’s the kind of details that get stored along with username-less. And the idea of this is that when you go to that website, you don’t need to type in your username. You just get a prompt with

the list of keys on your authenticator that say, hey, you’re on Google.com. I have a key here for Google.com on my key. You can log in with it. And you’d select that key. You’d put your pin in touch. And then bam, you’d sign in. No username, no nothing. The username is sent as part of that authentication ⁓ process. So this is where we start to get a little bit more into

you know, the more like what we see today version of things. ⁓ At that point, ⁓ this was circa 2020 was this kind of thing was being talked about. And this is about when I started to work on the WebAuthn Rust library. ⁓ Yeah. Funny, the funny reason I remember that is because I actually flew to my mate’s place in Sydney to work on that library for a week.

Josh Bressers (18:28) Okay.

William Brown (18:36) But was at the time during the Sydney 2020 bushfires. And so we ended up, so I went down there and luckily I was wanting to stay inside and work on stuff because we couldn’t go outside because it was so smoky outside. It was like orange skies, it was wild. And there actually was a, I think I went there before they, like when it was a…

Josh Bressers (18:49) Wow.

William Brown (19:00) like a lull in the fires, I wasn’t there at the worst part, but there was, I think there was a risk of me not being able to get back on time or something like that because there was too much smoke or something, so lots of issues with flights around there. horrific like event in nature, but that’s why I remember 2020s being when I worked on WebAuthn So yeah. ⁓

Josh Bressers (19:07) Wow.

I mean, that’s something.

William Brown (19:23) Anyway, so at this point username list is being talked about and you know some people look at it in a few different ways like look you know Yubikeys at the time they could only store eight credentials there were plenty of keys on the market that couldn’t store any I think I had one exceptional key that could store 32 I could be wrong I think Yubikeys maybe it’s a bit more than eight I think NitroKey was eight YubiKey was 25 but anyway it’s really low numbers though right like

Josh Bressers (19:40) Wow.

Yeah,

yeah, yeah.

William Brown (19:53) Think about your password manager. How many passwords have you got in that, you know?

Josh Bressers (19:57) Oh man, yeah, it’s a ton. Now if I remember correctly when I was researching this, you can’t remove those keys once you put them in the device, right?

William Brown (20:03) Now,

there’s ⁓ some caveats here. Most devices, yes you can. So for example, with something like a TPM, yes you can, because of the way that a TPM works. ⁓ So a TPM is basically a key wrap key, but it keeps it locally on your system rather than sending it to the remote end. ⁓ But for the YubiKey, it depends on what version of the key they are. Around this time, we were looking at…

Josh Bressers (20:29) ⁓ okay.

William Brown (20:32) Ctap 2.0. Ctap 2.0 had no way to delete these keys. I believe that keys could be updated, but the update process was really weird. You’d have to overwrite the existing key and it would only overwrite based on the relying party ID, think, as well. So you couldn’t have multiple users for the same site or something like that. So there was some caveats around them with Ctap 2.0. Ctap 2.1 pre, there was a…

Josh Bressers (20:52) ⁓ sure.

William Brown (21:00) Pre-release standard of Ctap 2.1 that as with all good things Ended up being shipped in a whole bunch of production devices So we’ve got Ctap 2.0, 2.1 pre and 2.1 because there were differences between pre to 2.1 Pre 2.1 pre and 2.1 did allow some management and deletion of these keys, but we still have that limitation even at that point of ⁓

Josh Bressers (21:14) Excellent.

William Brown (21:28) very limited storage on these devices. So around that time, there wasn’t really much takeoff of username-less. And even then, at that time, people seemed to be looking a bit more at the password-less as the way to go. And even then, it still wasn’t like super gaining traction, I would put it that way. Like people were still treating these as like second factor rather than as your combined multi-factor. So there was at least some good forward thinking going on here in the WebAuthn workgroup.

⁓ And up to this point, you know, like, so that’s the thing. So where username list changes is when our storage state in the device and, you know, the limited storage, this is what we start to call, at the time it was called a resident key, because the key is resident to the storage, it resides in it, or a non-resident key, which is your key wrapped key where the key has to be sent to you via the credential ID. This is later being changed to discoverable and non-discoverable credentials.

Josh Bressers (22:17) Sure, sure.

William Brown (22:28) which I think is worse naming because discoverable means I can discover the key locally on my computer without external information. Whereas non-discoverable is I need external information to find the keys that I could use. I think it’s a bit more confusing to track that. I tend to keep calling it resident keys. And funnily enough,

you know, like all good renames, the standard still refers to resident keys because… ⁓ Anyway. There’s something that’s still going on in this process here though. We still have this one-to-one relationship of key to device here. So at this time we still had, you you might have your username-less resident key on your YubiKey. You might have your passwordless…

Josh Bressers (22:57) Of course.

William Brown (23:21) with your YubiKey setup, but you’d still be enrolling like multiple keys. You’d have multiple YubiKey setup. Each one would be separate. Yeah. But there’s still like a one-to-one relationship where like you’ve got multiple of these hardware devices. You can’t just share state between them. So this is about to change though. Classic Chekhov’s gun, layout the info, pivot switch. And here is where we start to get to 2022. And this is where…

Josh Bressers (23:26) Yeah. Yeah.

guys.

William Brown (23:49) The name of the day, the word of the day comes up, Passkey. So, the origin of the word Passkey was actually Apple. And they revealed the name Passkeys, I believe, at their WWDC in late 2022. I could be wrong about the exact timing, but it was definitely 2022.

Josh Bressers (23:53) Okay.

William Brown (24:13) ⁓ and when they announced it, I don’t think they had any intent behind the name outside of just it’s a really approachable name for this type of interaction. ⁓ So rather than say passwordless or username-less, this doesn’t mean a lot to someone on the street and you know, it does get a bit confusing. Passkey is a really good name. It has associations with password.

Josh Bressers (24:39) Yeah. Yeah.

William Brown (24:39) but it’s not

a password, it’s a key, it’s a bit different, but it’s still like, I think it’s a really great word for it. ⁓ And when Apple revealed this, they ⁓ released their passkey offering ⁓ via their iCloud keychain and it had a number of… ⁓

I’m not going to say quirks. It had like a number of properties that were like strictly defined around how it worked. it was one of the early times where we saw synchronization. So Apple still stores all the keys in secure enclaves or at the very least with, you know, use secure enclave to decrypt a key wrap key or whatever. But, you know, my iPhone and my Mac, I could have a key, I could enroll a key on one, but then it would be usable on the other.

Josh Bressers (25:13) Yes.

William Brown (25:27) So this is where we start to see that that one-to-one device to key now melts away. Now we’ve got keys that can be on multiple devices. But not only that, I could take my key and I could actually airdrop it to my partner. So I could do the very thing that Netflix swore to destroy and share my login with a friend.

Josh Bressers (25:40) ⁓ wow.

William Brown (25:48) And you know, this obviously I think like there are obvious pros and cons to this. I think that you know, there it is right to have a way to share credentials with other people like sharing accounts is unfortunately something that we still do for a variety of reasons often financial.

⁓ But it does change the model. WebAuthn went from this one-to-one device to credential model to now you have many devices with one credential.

Josh Bressers (26:24) Yeah. Yeah.

William Brown (26:26) And there was another couple of properties about the way that WebAuthn on an iPhone at this time worked. And that was that it was following the username-less flow. It didn’t require a key wrapped key, it was storing that extra bit of detail in that state. You didn’t have to engage with it as the web server that was providing, that was authenticating the user, but you could if you wanted to. It was an optional nice to have and that’s all fine. ⁓ But at the time, know, Apple announced Passkeys

But there was no definition, right? It was, I’m going to call it a marketing term or a label for an umbrella of things. But, as we all know, no good word goes untouched when thought leadership exists. And so, people wanted to define what is a passkey. And there actually was like an evolution of different kind of community work group ideas around

What is a passkey? There in fact, I don’t think there was a great consensus for some time. So, you know, as this term evolved, like it started with some people advocated for a passkey is just any possible, you know, use of passwordless flows. You know, it could be your YubiKey, it could be your iPhone, it could be the TPM. It could even be a password manager, which is storing that private key as we’ve, you know, talked about. There were some people who then started to say, well,

Pass keys are what is on an iPhone, so it needs to be device-bound. It can’t be a security key, it has to be on like a laptop or a phone. It has to be a platform key. Can’t be a roaming key, it can’t be a password manager, it has to be on that, like a hardware machine. And built into that machine is the specific criteria I should say. Right? And then other people went, well, Passkeys are any synchronized credential. So a password manager is a pass key.

your iCloud key change passkey, but not a YubiKey because that’s not synchronized between multiple devices.

And then some people went a bit further and I seem to recall one group or one set of people or one company saying, no, no, it has to be synchronized and on a platform. So it has to be like an iPhone only. It can’t be a password manager. suddenly, like very quickly, we went through this speed run of like different ideas about what a passkey is. And you can actually kind of tell based on when a company adopted passkeys in their lingo based on how they treated them.

Josh Bressers (29:01) Nice.

William Brown (29:01) ⁓ when you’re the user. So,

Okta ⁓ at the time adopted Passkeys when they were device bound and not security keys, so you could only enroll platform authenticators initially. I think PayPal was they have to be synchronized and so they’d only let you enroll one because why would you need to enroll multiple? They’re synchronized, of course. ⁓ These things have since changed for the record, ⁓ so please don’t go and…

Josh Bressers (29:22) ⁓ yes.

William Brown (29:30) correct me in the comments, William, PayPal, can have multiple. Yeah, yeah, yeah, this was like three years ago, get off your high horse mate. ⁓ So different groups, depending on when they adopted the term, like it affected how they deployed this. And so this leads to confusion, the exact confusion that you notice, where it’s like, I can roll a pass key, but why isn’t my password manager popping up? Or like in my case, my email provider.

Josh Bressers (29:51) Okay.

William Brown (29:57) My email provider still thinks that they’re platform bound. And so, its menu comes up and goes, oh, you want to roll passkey? We’re going to force you into using your laptop touch ID. We’re not going to let you use a security key. I had some words with them in a support ticket about this. And they told me, oh, didn’t you see this grayed out link that says enroll another type of device? And I went, no, because you shouldn’t be playing with that stuff. Just let the user choose what they want. Anyway, point is,

Josh Bressers (30:11) Nice.

William Brown (30:27) There was multiple definitions of Passkeys and at the end, the one that gained traction above all else and has now become the FIDO definition of what a pass key is, is Passkeys are a resident key. So Passkeys map almost one-to-one to the definition of user nameless that I described before. It is a key that is stored with state in your device. It can optionally be synced. It could be, it doesn’t have to be, it could be on a Yubikey it can be at a password manager.

Josh Bressers (30:46) Okay.

William Brown (30:57) But the criteria is that it has to be resident. You have to be out of signing without typing in a username. And it kind of turns your key, like if you’re using a YubiKey, it turns it into a hardware password manager. It turns your password manager into like, you know, like it’s still a password manager, but like it’s got a little bit more like, I don’t know what the right word is I’m looking for. It’s like, it’s a little bit more locked down. Like you can’t change your username on the password manager side, because now that’s like a property of the key and some other stuff like that. So.

Josh Bressers (31:10) Yeah, yeah.

William Brown (31:27) So that’s what a passkey is. And so that’s where a lot of this confusion comes from is realistically that evolution. And today the agreed upon definition by Fido is it’s username-less. I individually and personally, I don’t like that. But the ship is sailed, that’s what a passkey is. That’s it. You know? So I’m like, I wish I would like to lie and tell you that passkeys are something else. But that would be dishonest. I…

Don’t like this definition, but it’s what it is. That’s what it is. Move on.

Josh Bressers (32:01) Okay, I’ve got

to ask what is the definition you want to see for Passkeys

William Brown (32:04) I prefer the

all possible authenticator version where it’s username-less, sorry password-less but can optionally be username-less. Because and the reason for this was that, you know, and this is a bit more historical, it’s still somewhat applies today but not so much. For a lot of consumers, they will never ever confront the issues with this problem. But for some people they will and the problem is that I still want to use my YubiKey and my YubiKey

Josh Bressers (32:12) Okay.

William Brown (32:34) is a model 5 but it was just it I was I sat down and I waited I was like Yubico is going to release new keys they’re going to release new keys I waited for six months and I went nah fuck it I’m giving up and buying new keys two weeks later they announced the new keys that had more storage

Josh Bressers (32:50) Of course,

obviously.

William Brown (32:52) Anyway, so I bought brand new keys, they’re some of the last ones on version 5.4 of the firmware and they can only support like 25 or 32 accounts. So, and there are plenty of other people, like we have a whole bunch, like I’m sure I’ve showed you this bag before, like my bag of, this is just one of my bags of keys here. ⁓ I’ve got some, like a Fido card, you know, like here as well, like a smart card for in fact things like that. You know,

Josh Bressers (33:09) Yup, yup.

William Brown (33:20) There are a lot of people out there, especially in tech communities, who do want to use these hardware keys and by forcing key residency, you’re really limiting how many keys they can store and potentially turning them into e-waste. People are either going to throw them out or be forced not to use them. And that to me, I think is wasteful because we can have username-less, but it doesn’t have to be the requirement. It should be an optional building block on top. And there is another aspect to this and that is

that by having so much state stored in the key, suddenly you now have a distributed systems problem, which is, okay, in passwordless, if the user updates their username, they just update their username on the website and move on. But with the pass key, you’ve now stored the user’s username in every key they’ve enrolled, and potentially a display name as well. Now, the user ID hopefully should be something like a UUID.

Josh Bressers (34:12) ⁓ right.

William Brown (34:19) that shouldn’t need to change. ⁓ But I can see some horrifying situations where it might. But something like a display name. If you go onto a website and you change your display name, say like I want to change my last name because I’m getting married, I’m an abusive relationship, I’m trans and want to change my name. All very reasonable reasons to want to change your name. People change their names all the time. Suddenly I can’t just do it on the website. I now need to also do that on every single passkey I’ve stored.

Josh Bressers (34:40) Yeah, yeah.

William Brown (34:48) There have been some attempts to like add APIs and stuff in the browsers to try and like update keys automatically when they’re found and all this other stuff, but it’s kind of like It’s trying to solve a problem of its own creation that didn’t need to be there, you know so So that’s where like I think it should just be all possible authenticators ⁓ But I’m not the one who makes the definition Fido’s definition is Passkeys or resident keys

Josh Bressers (35:04) Right.

William Brown (35:18) That’s what they are. ⁓ So yeah, outside of like, so if you see it today, like you’ll probably see like a couple of things out there that still like, don’t do the forced residency. It’s very rare though. ⁓ But most of them have just given up and go, yep, screw it. We’re burning your, you’re storing something. So that’s what a passkey is today. It’s, it’s username-less. That’s what it is.

Josh Bressers (35:46) Okay, that makes sense. I feel like your explanation is the best I have ever heard by a wide margin. So thank you for that. Now, there’s an aspect of this, I think, that I would love to hear your opinion on is there are websites that I have logged in with the passkey and then it asks me for my two-factor authentication code. Or it emails like, we sent you an email with a code in it or something like that. And I’m like, this…

William Brown (35:47) Yep, yep, it’s.

That’s alright.

Mm-hmm.

So.

Josh Bressers (36:14) Completely def- this is- aw it makes me so mad

William Brown (36:17) Now,

yes and no, there is actually some very funny extra definitions of Passkeys I’ve seen since. So, remember how I said depending on when you adopted Passkeys you’d define them differently? So, even after Passkeys or resident keys became the de facto definition and the FIDO definition, there are still some groups of people who have somehow managed to define new names for what a pass key is. Just last week, I saw Enroll Your Pass Key referring to

Josh Bressers (36:28) Yes.

William Brown (36:47) U2F as in the second factor only. I’ve also seen Passkeys referred to Yubi keys only as the passwordless in a major identity management product where you can’t even use your phone or anything. It has to be a Yubi key and it has to be that. So there’s lots of wrong definitions but talking about the pass key with the extra factor there, I don’t like it. I don’t think it’s needed.

Josh Bressers (36:49) ⁓ sure.

William Brown (37:17) But I can see why they might do it depending on their understanding of things. And this is the thing is we have to also try to talk about what is the implementer’s understanding of Passkeys? Are they trying to resolve a threat or have they misunderstood? So it could be that they’ve misunderstood how a pass key works and they don’t understand how the user verification step is performed.

And so they don’t know. They might think that the passkey is only one factor and in order to provide MFA they need another factor. Right? Very easy mistake to make because you’re only saying, passkey is one factor, right? It’s like password but better, it’s key. You know?

That could be a legitimate misunderstanding for the same reason why you’ve had misunderstandings about what Passkeys are. It’s not well explained in a lot of places. The alternate is that ⁓ going to something like your risk models or your threats is, as we mentioned, is that ⁓ since Passkeys can now be stored in a lot of different things, they’re no longer just a security key with a guaranteed and a hardware secure enclave. It could be a password manager. It could be someone’s iPhone.

It could be a code from the back of a cereal box. It’s…

There is an argument that some people are hedging their bets and saying, well, what if that’s a weak passkey implementer? What if it’s a low quality store of that private key? Yes, we’ve blocked the phishing attempts, but we still want something else. I don’t think it’s strictly necessary. And I would argue that there are better ways to actually, if you have that concern about the quality of where passkeys are stored, just use attestation. Way simpler.

Josh Bressers (38:49) right.

William Brown (39:09) ⁓ But maybe that’s the thing. I’m trying to give them the benefit out here and I can see it as either of those things. I don’t agree with it. I don’t think you should. If you’re to do Passkeys, it should just be pass key and that’s it. ⁓ And ultimately, as like a deployer of a web service or an identity service, you have to make informed decisions about what

credentials do we allow someone to use? You know, like the same way that you have like a password policy and by password policy I mean how long should the password be policy not a how many Egyptian hieroglyphics can I fit into four characters policy? ⁓

Pass keys and their security, you are welcome to understand that similar to a password policy. Where is your threat level? Do you just want to make sure that someone can’t be phished? Screw it! Let any pass key you want register because at that point you’ve stepped the bar up from passwords, you don’t have password reuse, you don’t have phishing to worry about, you don’t have to worry about, you know, signature replay, stuff like that. You’ve already stepped up by a long way, so who cares if they’re using

codes from the back of a cereal box, at some point the user has to take responsibility for their own key storage and key hygiene too. If you are like a business and you’re more worried about like compromise of these things, then yeah start to look at things like attestation. Ship out like boxes upon boxes of Yubi keys to your users and you know like give them those keys.

You can even take that further. There are enterprise deployment profiles for YubiKey now where you can get the keys, enroll them in your own CA and then ship them out to make sure they’ve not been tampered with and stuff like that. And at the very far end of this, if you’re a three-letter agency, then why are you getting security advice from this podcast? You’ve got better people to talk to. ⁓ So I think that’s the thing is that there is… ⁓

Josh Bressers (40:57) Yep. Yep.

Seriously.

William Brown (41:16) Like there is that spectrum and I think ultimately like for most deployments it comes down to one or two things like either just let people enroll whatever passkey they want, it’s better than a password, move on or use attestation throw out YubiKey like candy, move on. know? So, yeah.

Josh Bressers (41:32) Yeah,

okay, that makes sense. Now I have one other question I’d be curious on your thoughts.

William Brown (41:38) I’m still coming

back because I’ve actually taken a note here about how QR codes work. So I want to explain that to you by the way.

Josh Bressers (41:43) good. OK,

so yeah, let’s do that. Do that now. That would be better because my question my last but my question is probably better suited for the end. So yeah, we’ll QR codes like I’d love to know.

William Brown (41:47) Okay, cool.

Okay, cool,

So now we come back to the QR code thing. ⁓ And to jump back a little bit in our story, we’ve started with Passkeys, and talking about Passkeys as resident keys here, we now have that defined state where the key has to be stored in something. And so people started to think about, well, if I have, say, a YubiKey, like this one here.

I can plug it into my laptop and then I can take it out of the laptop and then hold it against the back of my phone and then log in across multiple devices. It can move. I can’t do that with my phone. Like, I could rip this cure enclave out of my phone, no guarantee my phone will work again, but it certainly won’t work if I try to smoosh it onto my laptop, right? So suddenly you have this problem where, like, it’s all well and good if you’ve got an iPhone and a Mac and everything is synchronized, but that’s not how the world works, you know?

People are messy, they have very disparate and ⁓ homogenous devices. I actually remember the right one there. ⁓ My veterinarian, Dr. Fiance, is rubbing off on me with all her fancy terms. ⁓

Let’s say that you have an Android phone and a Windows PC. There’s no synchronization between those two. So how do I get… So let’s say that I’ve just signed up to a website on ⁓ my phone. And I’ve signed up to something. Well, I can’t move that key to my machine to then log in. So what do I do? I could do the whole password, passkey reset flow.

then enrol another passkey on my device. But, ⁓ that’s a whole thing and that’s emails and everything else. And that’s how a lot of people do.

Josh Bressers (43:43) in all seriousness, more than one service

but more than one service I use does not allow multiple Passkeys.

William Brown (43:50) Yep, and those services, I would like to know which services, but also they’re wrong. ⁓ Very wrong, you should be allowing multiple. ⁓ Like, if you’re gonna, like, sure, maybe have a limit, like, setting up a bound, fucking, who the hell needs more than 16 Passkeys, like, that’s a bit wild. ⁓ Says the man with like 20 keys on his desk, but anyway, they’re not all in active use. So the thing is, so what they do is there was a way of, hey, I wanna be able to bootstrap this device from this device.

Josh Bressers (43:55) Yeah, obviously.

Right. Right.

William Brown (44:20) And so that’s where the comes in. That was the original name of it, was CABLE. ⁓ And I don’t remember what it stands for. It’s something, something Bluetooth Low Energy. You know, actually I think it’s CTAP Authenticator over Bluetooth Low Energy maybe. I could be wrong. ⁓ And it got renamed to Hybrid later ⁓ because of reasons. Anyway, so what would happen is…

It’s changed over time, I’m sure I’m going to get the order of this wrong. What would happen is your laptop would pop a QR code. But at the same time, it’s also started to advertise a Bluetooth beacon.

What happens is then, your phone, you scan that QR code and that gives you information about the Bluetooth transmitter. Your phone then connects to the Bluetooth and they both exchange and get a, I think like a nonce or an ID. It’s been a while since I’ve reviewed cable how it works by the way, so I could make a mistake in this section, but this is the, this is the close enough version. Then both sides end up with this nonce or ID.

Josh Bressers (45:30) It’s close enough, I’m sure.

William Brown (45:37) Both devices then contact a cable broker, which is an internet service or an internet relay. Cable brokers today are run generally either by Apple or Google, depending on which device you’re contacting from, because they have this mixed in with your IDs, blah blah blah. Both of them then establish this tunnel through the third party. But, using that bit of information as an exchange at the start, they derive a shared key.

for the encryption over that tunnel. So the broker cannot see anything in the middle. Like it is privacy preserving, that’s fine. Then what happens is your machine, when it receives that the phone has connected via the tunnel, it then sends a CTAP request, the same kind of CTAP request that would go to your USB device. I believe it sends, I think it’s CTAP. It sends that over the tunnel via the internet back through to your phone, which then gets it and actually

does the signature, validates and says do you want to authenticate this, it does the signing and then sends it back via that tunnel to the machine and then the signature is used.

Josh Bressers (46:49) That is witchcraft.

William Brown (46:50) I

want to say in this one, the reason I don’t understand cable as well is because I didn’t write any of the code to do with this in WebAuthNRS. That was fully the domain of my friend Michael, his online handler is Nicholas. Absolute legend, smartest guy I’ve ever met. He basically just sat down and reverse engineered it in a week. ⁓ And at the time I don’t think it had very good docs. Like originally I think the phone advertised Bluetooth and then the laptop connected in.

But then it got swapped to the other direction later and now the laptop advertises. ⁓ And so there have been people that have tried to talk about, there’s these attacks on Passkeys and all the phishing stuff and all of them have turned out to be bonk. There is a single attack we know of against cable. ⁓ And it’d be very very hard to pull off. But that is for another time.

Josh Bressers (47:45) enough that the process you just okay okay that’s I’ll wait we’ll wait but that that process you just that’s ridiculous like

William Brown (47:47) I believe that would count as public disclosure but… Yeah. Yeah. Yeah, that’s how it works. Yeah. It is

bonkers. So Michael actually sat down and not only did he write all of this stuff, he wrote his own cable tunnel broker if you want to write, if you want to run your own. And not only that, he actually went further and I think he found a way to do it over RDP. So you could do cable over RDP to a remote Windows machine or something like that. It was…

Because RDP allows you to forward those requests as well. Think about it, you’ve got a Windows remote desktop setup. You plug your YubiKey into the head machine, but you actually contact your server there. You’ve got to be able to send that CTAP to a remote machine. Then you’ve got to do cable over that whole thing, by the way. ⁓ yeah, it’s wild.

Josh Bressers (48:44) I don’t even know what to say.

William Brown (48:45) So that’s how

that works. Yeah.

Josh Bressers (48:48) Wow.

I will, the next time my phone fails to log me in using the QR code, I will be much more understanding than I’ve been in the past.

William Brown (48:56) Well, that’s the thing

is that both of those devices have to have line of sight to the tunnel server. But also, ⁓ me as an Australian, I get to gripe about this all the time is a lot of these services are deployed in America. So what’s the latency from Australia to America like?

Josh Bressers (49:17) In a

couple seconds you’ll get at least on that I imagine.

William Brown (49:21) I reckon cable takes me about from getting the QR code to finishing the login, it’s about a minute.

Josh Bressers (49:28) Whoa, it’s that bad? That’s terrible. Wow. Holy cow.

William Brown (49:30) Yeah, it can be really slow. ⁓

It might have improved, I don’t know, but last time I was mucking around with it, it was about a minute. ⁓

Josh Bressers (49:37) Wow.

Yeah, that’s unacceptably slow. I mean, think 10 seconds is too slow.

William Brown (49:40) But

at the same time, think like cable…

was created to solve a problem and that problem was how do we bring on a new device in you know these homogenous device environments I don’t know if it was intended to be this is how you’re meant to use a passkey all the time but that is certainly how some people are treating it is hey you want to log in use your phone and I actually think that process for most people is annoying as hell ⁓

Josh Bressers (50:10) Yes.

And in fact, it’s one of the reasons I don’t put Passkeys on my phone hardly ever, because it’s like painful and it feels so I have a Linux machine. That’s my work machine. Most of my computers are Linux computers and I have an iPhone and it’s because I rage quit Android at some point because of end of life things. And yeah, like it. That is why I don’t use my phone for Passkeys, because it just sucks.

William Brown (50:15) Yep. Yep.

Yeah.

Yeah,

and so I think that is a genuine thing, is that that experience is not an experience that I think is good day to day. And I think that’s ultimately a really big part of this, is it’s one thing to talk about passkeys and their definitions. What we haven’t talked about at all is the user experience here. And ultimately, the user experience is so varied and so different from person to person, it depends on your hardware, your understanding.

Josh Bressers (50:57) Yes.

William Brown (51:01) your machines, like what OS, what country you’re in, like things like that. My fiance is ADHD and that comes along with it, the benefits and joys of object permanence issues. And so she’ll often put her phone down and go, ⁓ crap, where is it? So for her, using something like cable is like, she’d be sitting at her PC, needs to log in and then she goes, fuck, where’s my phone? That’s not a fun experience for her.

Josh Bressers (51:26) Right, right, yep, yep.

William Brown (51:32) And so that’s the thing, there’s all of these issues with the user experience that come out of these different things. So for example, one of the consequences of embedding so much state in Passkeys and me being resident keys is that they are bound to that relying party ID. Now believe it or not, the key wrapped keys aren’t. Someone argued with me on Mastodon about this the other day and I stopped responding because I think sometimes the best thing on the internet is to just not engage. ⁓

Josh Bressers (51:59) Yes.

William Brown (52:02) The thing is that the key for key wrap key in CTAP, it doesn’t care what the relying party ID is, it will sign it. Because if you’re trying to phish it, you’re signing with a different relying party ID, you’re not going to get anywhere. But the relying party ID, and I’m going to caveat that with maybe that’s changed in CTAP 2.3, which I think is a thing, but I tested this literally last week with CTAP 2.1 devices and I was able to take a key from

Josh Bressers (52:13) Right, right, right, right.

William Brown (52:30) example.com to fishme.ru and it signed both. You know, and I’ll, but I bypassed browsers. I was directly using Fido HID RS and Authenticator RS, which is the library used by Firefox. And Fido HID RS is our library from WebAuthn, both of which implement the CTAP standards. So directly talking to a key, it will let you sign any relying party ID you want. The benefit of this is that let’s say that I changed my domain name.

I don’t have to change anything. All I do is send a new RPID and then the key will just work.

Josh Bressers (53:04) ⁓ sure.

William Brown (53:05) Because it’s still my domain name, I’m not being, I’m I’m phishing myself if you want to call it that, but I don’t care because I’m the one changing my name. Whereas when you store the relying party ID in the key, now we have to have a way to say, hey, the relying party ID was originally this, now it’s that. So there are things called related origin requests, which can say, hey, I’m doing your request for A, but I’m coming from B. I can’t remember which way it goes. I’ve, it’s one of the areas of the spec I’m a bit weaker in.

But it’s to try and solve this problem. And we actually saw this happen recently. I think it was about a month ago. My sense of time is really bad. And you might know where I’m going with this. The Twitter to X passkey migration. And this is why it failed. This is why I had problems, is because those RP IDs are stored in the key. And so suddenly everyone’s password managers or keys would have said, uh-uh, that’s not, I’m not going to that. There could have been ways around it. I’m not a hundred percent sure. haven’t.

Josh Bressers (53:39) Yeah. It’s, it’s, it’s, yeah, yeah. Yup, yup.

William Brown (54:02) done like a full analysis so I’m not going to comment on whether it could have been resolved or fixed or whatever. ⁓ But that was definitely a significant contributor to that headache. ⁓ So like ultimately that’s the thing is like what I’ve mentioned here is like we’ve gone through this evolution and we’ve kind of got this entire spectrum now of like this thing of like we went from these stateless cryptographic single factors to a stateless self-contained multifactor to a

it’s got a little bit of state. So now it’s like they synchronized moving around nebulous things and like all of this extra state and all this extra and a lot of the things that are going to the WebAuthn specification now are actually to do with how much state we are having to store in these keys and about manipulating and updating that. So for example, the automatic username renames ⁓ on key updates in the background. ⁓

Josh Bressers (54:48) Aha!

William Brown (54:57) things like the related origin requests to allow it because, well, the RPID is stored in the key. Therefore, we need a way to signal that we’re changing that name. All of these things are being added to resolve these distributed system problems that have now occurred as a result of storing more state in the key. ⁓ And so that’s realistically where WebAuthn is continuing to go is trying to, I think, getting through the teething issues, if I want to call it that. ⁓

of having stored so much data in the authenticator. yeah. And then of course things like, you know, allowing devices to be used across like from device A to device B like cable. ⁓ Yeah, so that’s kind of where a lot of this has been going and changing. That’s where a lot of the changes have been. Yeah. cool.

Josh Bressers (55:43) Okay, this is great. You answered my question. Like it was the

usability question of why, I mean, I think…

William Brown (55:52) Well,

there’s still so much more to talk about about the usability question because there’s so many… Yeah, it’s a complicated one. It’s so… Yeah.

Josh Bressers (55:55) There is, right, right.

It’s hard, but okay, so here’s,

here’s how I want to close this one down. Everything you’ve described, like I think the technical issues all make sense and it’s hard and it’s weird and it’s an evolved protocol, which those are always manky for their own reasons, whatever. But I feel like the, so the usability aspect can’t be understated in this whole story.

William Brown (56:09) Yeah.

Josh Bressers (56:24) And I think that’s why a year ago, no one would shut up about these things. And now a year later, I feel like no one talks about Passkeys except to complain about how they don’t.

William Brown (56:33) I was going to say I don’t think I’ve seen a compliment in the direction of Passkeys in the last year. ⁓ I will caveat that with publicly, I have seen compliments about it in the IDM that I wrote because we put usability very high on the list. But that is, I’m tooting my own horn there and that’s…

Josh Bressers (56:47) Nice.

That’s awesome. That’s good. That’s good. But, here’s

William Brown (56:56) But that’s

we… But that’s thing. You’re right. Usability is such a thing because a system can’t be secure unless it’s usable. And if it’s not usable, people will want to avoid it. And that is actually what has happened with Chloe. And Chloe is my fiancé. She has… Being a security person and an auth nerd, I have tried to introduce some of these things to her and see how it goes. And she’s sworn off passkeys.

Josh Bressers (57:25) I believe it.

William Brown (57:26) She,

like we tried a bunch of different stuff. We tried the iCloud keychain, I’ve tried Bitwarden, I’ve tried like a, I can’t remember what the other one was, but there was something else we tried. And then at each time she was just like, yeah, it drives me up the wall. I had, tested with another person who was an accountant and she had an Android phone and her first reaction when the, when it took her out the browser and popped the full screen.

and was like, you’re enrolling blah blah blah she was like, my god did you just hack my phone?

Josh Bressers (57:58) Ahaha!

William Brown (57:58) And

I think that’s the thing is that we don’t just have a usability issue, we have a communication issue. And that communication issue is already evident by the fact that this podcast exists. This episode of this podcast exists, for example, where what is the passkey? We’ve spent an hour having a talk about it because people aren’t getting it. And that’s the thing is if we have intelligent, technical people who are subject matter experts in technology who are struggling with this,

Josh Bressers (58:12) It’s fair.

I know, right?

William Brown (58:28) What about intelligent people with subject matter expertise outside of tech? know, like, I’ve, the number of people outside of tech where I’ve explained this to them and some of that, like, you know, the big one that I continually see as the failing in communication is ⁓ using touch or face IDs, both Android and iPhone here are with this, is that it is still communicated in a way where it looks like you are sending your fingerprints over the internet.

Josh Bressers (58:32) Yeah, yeah, for sure.

William Brown (58:59) And that is the number one issue that I have seen with people not wanting to adopt Passkeys is they go, I don’t want to send my fingerprints over the internet because I can’t change my fingerprints.

Josh Bressers (58:59) interesting.

William Brown (59:11) And the way that Passkeys work, they do not send your fingerprint over the internet. Categorically they do not. But the way it’s communicated tells people that they are. And so they go, well, I don’t want that. And then they go, I’m going to avoid it. And then you also see issues where like you see websites like I think I saw someone complaining about Amazon where you’d log in and with no consent, no warning, it would pop a thing in the thing that says, enroll a pass key now. And people go, what the fuck is that? And then they…

Josh Bressers (59:36) Yes.

William Brown (59:40) they don’t know what it is. suddenly they don’t know, like there was never consent, informed consent, able to be given by the user to then engage with that flow. And so they then go, well, I don’t know what this is because I don’t know what it is. I’m going to click off. And then potentially they’re going to keep clicking no on it. ⁓ And so like, this is ultimately like where we’re at is I think that ⁓ the usability issues are really coming to bear and ⁓ I don’t

know how that’s going to be addressed. Like even, you know, what I said about my email provider, they try and force people into using their laptop. What if someone or their built-in platform ID I should say. What if someone doesn’t want that? You know, like that, how are they going to navigate around it? I know how to, because I understand this stuff. How’s somebody else meant to, you know? So yeah, honestly, I, I don’t know how I, I personally think that consumers will

broadly not use Passkeys. I think we will see a lot of technical people like ourselves potentially use them. think that people who, like the kind of group of people who already engage with a password manager are the ones who are likely to engage with a pass key. You know, they already know about some of these elements. They’re a little bit more informed about some of the security issues and they’re more likely to engage with that.

Josh Bressers (1:00:56) Yeah, yeah.

William Brown (1:01:06) People who don’t use password managers tend to be the ones who are a bit more, I don’t want to touch it because Passkeys realistically cannot work without a password manager of some description if you want to call it that. ⁓ So I think largely consumers will probably not adopt this. I think businesses will adopt this. think businesses are actually in an excellent position to do so because they have a much more controlled environment. They can control the devices that get sent to users. What?

Josh Bressers (1:01:15) right.

William Brown (1:01:32) You know, they can do things like your enterprise deployment profiles, whether that’s like with Apple or Windows. They can set up YubiKey’s. A bank here in Australia already does YubiKey’s for everything. Or at least there is one bank I know of that does this. But saying this, this bank previously used to use actual smart cards, like proper cryptographic smart cards for everything. Like you would walk into this bank and a teller is going to tell you their bank balance. They whip out a smart card, put it in, pin.

Josh Bressers (1:01:44) Nice.

William Brown (1:02:02) the works, like it was hardcore. ⁓ For anyone who’s Australian, that’s Commonwealth Bank that does that. They are now using YubiKey’s. I don’t know if they’re using the YubiKey’s in smart card mode though. They probably are. But they have full end-to-end everything. So in that environment where it’s very controlled, think businesses have a great opportunity to do it. ⁓ think, yeah, but yeah, for general consumers, I’m still not sure how this is going to go because

Josh Bressers (1:02:02) Wow.

Yeah. Yeah.

William Brown (1:02:30) There are still other usability traps that people have. ⁓ An account that I follow on Mastodon, ⁓ think Royce Williams, he’s very involved in like Fido and Yubikeys, he’s very like invested in that stuff. he was one of many people who have fallen victim to the fact that Android Passkeys will just sometimes blow up.

Josh Bressers (1:02:41) Yeah, I follow, Royce.

Whoops.

William Brown (1:02:55) And so he was there like, well shit, my Android now can’t sign anything, I can’t register anything. He tried resetting the firmware, resyncing everything. I don’t know if he ever resolved the problem. We’ve seen this with a few people where they’ve got Androids and just one day it stops enrolling keys and it could stop signing them. And we don’t know, we’ve never had an affected device ourselves with our hands on it, so we haven’t been able to debug it. But we have seen community users in the WebAuthNRS community with this. ⁓ I…

Josh Bressers (1:03:05) Wow.

William Brown (1:03:24) I got infamous, I’m going to call infamous, for a very angry rant blog post that I wrote about how my iPhone destroyed all of my Passkeys four different times and then destroyed all of Chloe’s as well at one point. ⁓

Josh Bressers (1:03:42) my. You’ll have to send that to me. I don’t think I’ve read that one. Yeah, yeah. good, I’ll put it in the show notes for anyone interested.

William Brown (1:03:46) okay, that one’s a proper ⁓ rant. ⁓

And for context, I was very angry about that situation. ⁓ So I was very emotional and whatever. But also, I think that’s a problem. And this is a really difficult thing. And I do feel for the engineers at Google and Apple who are deploying these things, but at the scale of Google and Apple,

Josh Bressers (1:04:01) It’s fine. I love a good rant.

William Brown (1:04:15) even a 1 % failure rate is hundreds of thousands, millions of people. If this is a 0.5 % failure where people are having these Passkeys wiped out, but that was their only pass key store, like you said, there were websites that you use that only have one pass key allowed to be enrolled. If that was my one pass key, that’s it. What am I meant to do? Like now I’ve suddenly got to go and reset them all. And this undermines confidence in the technology as a whole. ⁓ And so like,

I really feel for those engineers, like it’s a really difficult thing to fix. when it’s happened to me and it’s wiped out my stuff, like I’ve even tried to debug it on my phones, I’ve cracked out the console, like everything. I’ve never been able to work out what is, what it is that causes this wipe out to happen. I haven’t had it happen since, but like that is because I’ve stopped using that. It could be fixed. It may not happen anymore. So.

Don’t make your assessment based on what I’m saying here. This could be an old problem. It could have been resolved. But it happened to me before. It’s undermined my confidence. I’ve moved away from it. And this is a risk for consumers is when their confidence is undermined, they’ll step away. yeah. ⁓ So I would generally, like generally my advice for people is get a YubiKey. Use that for your most valuable services and accounts. So things like your email.

Josh Bressers (1:05:24) Yeah, yeah.

William Brown (1:05:38) is a very critical one as email underpins like password and credential resets for some of your services. So a YubiKey on that is absolutely critical. ⁓ Potentially if you’re involved in like software engineering or open source code development, potentially on your GitHub, know, especially in terms of like account hijacks, all that fun stuff. ⁓ And then, you know, outside of that, use a password manager, take backups. A lot of password managers do allow you to take local backups.

⁓ And there are ways that you can protect yourself in case something does go wrong in those cases. ⁓ And that’s what I would advise for a lot of people. ⁓ And if you are going to use these things, like enroll multiple. Like yeah, sure, go on. Use your iPhone keychain, but enroll something else as well as a backup. You know, it’s always a good idea to have backups because we’re not just talking about a password that I can print out and put in my safe. We’re talking about something where it’s a lot harder to kind of recover from a disaster using more traditional like…

means. ⁓ So yeah, take backups, have multiple YubiKey, have your ⁓ user password manager, and yeah, that’s probably where I’d leave it.

Josh Bressers (1:06:51) That holy cow, man, this has been amazing. Just an amazing story. I feel here’s, here’s what I will say. Here’s what I will tell you, William, after all this. And you’ve been talking for a long time and I truly appreciate it is I know, no, I’m, love this. This has been amazing. I feel more confident in Passkeys now than I did before for the simple reason that while they have many, many inherent issues today.

William Brown (1:07:05) Yeah, sorry, I’m sorry this is a long one.

good.

Josh Bressers (1:07:21) There are people working on this and you obviously they’re very aware of the flaws in the drawbacks. And my suspicion is no one’s talking about them because they do kind of suck today. And this is going to be a boil the frog where I think one day it’s going to be like, crap, remember when these things sucked and we know and used them.

William Brown (1:07:27) Yeah. Yeah.

Yeah.

Yeah, potentially that’s the case. think that, I still think a lot of those changes are gonna take time and years, ⁓ but we’ll see how it goes. ⁓ I’m certainly not one of the, I will say I’m certainly not one of the people involved in that work. I’m just an outside observer at this point. I just make WebAuthNRS work and play nice and that’s it. But there are other people who like, cause I’m not the one in control of these platforms. Like ultimately it comes down to,

Josh Bressers (1:07:43) years, years and years.

Right, I bet in 10 years.

William Brown (1:08:04) Chromium is basically the gatekeeper of the standard. If Chromium doesn’t implement it, then suck shit, no one will. So whatever happens there is what is really going to define how the standard improves or not. ⁓ yeah. Yeah. No problem. Always happy to join. Take care. Have a great day.

Josh Bressers (1:08:09) Yeah, right, right.

Awesome. Awesome. All right, William. Well, until next time, man. Thank you so much.