Episode 304: webauthn and webauthn.io

---

This week’s transcription is brought to you by Alectrona

James Smith:
This week’s episode of the Mac Admins Podcast is brought to you by Kandji. Kandji’s latest release, Bookmarks, lets you give your users, links to the resources they need at work via the Kandji self-service app. You can put in links to websites, repos, files, or other materials, anything that they need. When you deploy Bookmarks along with apps and scripts and self-service, your users can easily install approved apps, run scripts, and find the resources they need for work. It’s all in one app.
To learn more, head on over to kandji.io, that’s K-A-N-D-J-I.I-O, or join the Kandji channel on the Mac Admin Slack to say, “Hi,” and see what they’re up to. Thanks to Kandji for sponsoring this episode of the Mac Admins Podcast.

Tom Bridge:
Hello and welcome to the Mac Admin’s podcast. I’m your host, Tom Bridge, and Charles, it’s great to see you today. How are you?

Charles Edge:
I am great. It was a lovely warm day. I got to have lunch with Ed Marzach. He says hi to everybody.

Tom Bridge:
Hi, Ed.

Charles Edge:
Hi, Ed. Yeah, it’s just been a wonderful weekend. I finished some tools that I started writing a few weeks ago, because I had some downtime and yeah, how about you?

Tom Bridge:
I built garden beds with my brother-in-law today. We’re out here in California visiting my parents for the week. It’s spring break or February break, winter break, part two, the revenge. Not sure what that it is, but we get a week off in February in DC. So we came out, my son and his cousin spent all afternoon just like thick as thieves playing Nintendo, running off to the park. It’s been kind of idyllic, really. They’re out there living their best lives while all of the adults do physical labor. So the gardens just about ready for springtime here, and it was a perfect day today. It was a great day to spend out in the sunshine. So Marcus, how are you?

Marcus Ransom:
I’m doing all right. I did some gardening as well yesterday, and so for once the injuries on my arms are not from Alfie, they’re from shrubs and sticks and all sorts of other things. But Tom speaking about catching up with people, we might be able to catch up soon.

Tom Bridge:
I’m looking forward to this. We’re going to get a chance to get coffee together in just about six weeks. As this goes out, I guess it’s like four and a half. But yeah, we’re going to hang out together in Melbourne in four to five weeks towards the end of March at the X World Conference.

Marcus Ransom:
Really looking forward to it. It’ll be good to see you.

Tom Bridge:
I’m thrilled. It will be fantastic to see you in person. We’re going to figure out a way to record in person while we’re down there and have a good time and have some great guests. So keep your eyes on that and for those ready to attend a new conference or an old conference, again, come see X World in Melbourne this year. It’s in Melbourne, not in Sydney this time. And at the risk of making enemies, I actually kind of like Melbourne better than Sydney, but that may have just caused too many rifts, so I’ll just leave that there.

Charles Edge:
You’ll be enemy number one in ANZ Mac or ANZ.

Tom Bridge:
ANZ Mac, yeah, ANZ. But at least I’m down with the Tim Tam Slam, so I know what that’s all about. But it’s not just us this week we’ve got an incredible guest, Matt Miller. Welcome to the Mac Admin Podcast.

Matthew Miller:
Hey, thanks all for having me. I’m very excited to be here.

Charles Edge:
And just to set the picture for what we’re going to be talking about today, Apple’s version of passkeys are the latest piece of a sprawling identity picture for the Apple platform that isn’t widely supported just yet, which is a perfect time to start learning about it in my opinion. Passkeys aren’t just Apple. They’re supported on Mac, Windows, Android, and even in our browsers with different key stores, so to speak. And this evolution in WebAuthn capabilities means we don’t need physical tokens, although that’s still an option as we’ll get into later, to have a second form, a second factor in our authentication and authorization flows, nor is that other factor tied to a phone number, making it more secure theoretically. But for admins, there are plenty of questions we need to figure out. What do we have instead of a username? What do we have instead of a username? And what is there in lieu of a password?
Like there’s different terminology, so to speak. That means different things to be specific. As we develop solutions that work with WebAuthn, we often use a reference implementation @WebAuthn.io to test functionality. And Matt, you’re one of the people behind that site. So thank you for joining us, and we love to kick things off with a little origin story before we delve into the site and the protocols. So would you mind taking us through how you got into WebAuthn and doing this type of stuff?

Marcus Ransom:
How you got into computers in general as well. Feel free to take it right down.

Charles Edge:
Oh, sure. Yeah.

Matthew Miller:
Okay. The year is 2000 and I mean, if you want to go that far back. So historically, I have been mostly a web focused developer. My first introduction to the world of programming was HTML, CSS, JavaScript around the turn of the century. And from there, there was something about the ability to control the computer that appealed to me and I decided to stick with it. And ever since those humble beginnings, I have dabbled in all kinds of things. I’ve done some Visual Basic. PHP was my first web centric language that wasn’t front end. I wrote a whole bunch of stuff in there in PHP as was kind of the way things were back then. As time went on and evolved, I branched out into, did a little bit of .Net, some Python, is now one of the backend languages that I like doing, and I’ve kept up this full stack development preference over the years. So it’s kind of funny. I’m in security now. I’m a tech lead at Cisco working on Duo and their passwordless offerings, and it was sort of serendipitous how I ended up where I am today.
So for the last, I’d say, I’m a couple years now at Cisco, so the last four or five years prior to getting to Cisco, I was in the world of consulting work, like agency work, so doing lots of full stack web stuff for agencies. And so there was always this turnover of work. I would be on a team, we would invest the time in building something out, and then of course there’s the handoff to the client and then you’d move on to the next thing. And that was great for really expanding just general capability and testing out the latest and greatest when every project was an opportunity to greenfield. Well, that’s great for picking up the flavor of the week, but it must have been about a year or two before I ended up at Cisco where I heard about Web authentic, because I found WebAuthn.io and I found WebAuthn.guide, both of which were websites that came out of Duo Labs, which was Duo’s effort to kind of invest in the future. I’m sorry, maybe I’ve gone way off the deep end with this, but…

Charles Edge:
No, no, it’s a reference. It was, I guess a reference implementation, right?

Matthew Miller:
Yeah. You could use it for registration and authentication, and I was perfectly outfitted. I had my MacBook with a Touch ID sensor on it, and this was just being able to feel the WebAuthn authentication experience, so to speak. It just stirred something within me and I was like, “This is a really slick way to log into things. What is this all about?” And so from there was a long journey that I could go on much longer, but the short version of it is it’s just inspired in me this hunger to want to learn about WebAuthn.
So I dove real deep. I wrote my own little MVP of something WebAuthn Powered, which became the foundational code base for what my own personal WebAuthn library, which inspired me to join Duo. And now I kind of took those same learnings and rewrote Duo’s Pie WebAuthn library as well. So I’m also the maintainer of the Python WebAuthn library in addition to my own. And then after building that, I rewrote WebAuthn.io, because WebAuthn had come so far since WebAuthn.io in I think 2019 or so is when I kind of caught interest on it. And in the two or three years until I rewrote WebAuthn.io, things had evolved so much. I was like, people love this site. Let’s show them the latest and greatest of WebAuthn. And so there you go. Here’s my origin story.

Charles Edge:
Love it. And WebAuthn has been so useful in testing all the things with passkeys on the developer’s side, and I know you got there, I know you were working on your own implementations, but do you mind telling us how that specific project got started within Duo Labs? I mean, I assume that some of the people from Duo were on the standards committees and kind of carried it forward?

Matthew Miller:
Okay. So Duo Labs was ending just as… Had basically just ended just as I was coming onto Cisco. So there were a couple of people that I knew of who were on Duo Labs, Nick Steele and Jeremy Erickson, I’m going to name-drop that were very influential in those very early days of trying to figure out what this technology was. Adam Goodman, I think, was helping out with that as well. And they were very early participants in the WebAuthn working group, the web authentication working group, a W3C working group that drives the evolution of the browser API itself. So they were there, they continue to be there to this day, actually, Nick Steele is very active on the working group side of things.
So they were very influential in helping kind of get WebAuthn to where it is, off to a solid start I’ll say. There’s been, as is the nature of any working group, there’s lots of effort that goes into these technologies. But yeah, Duo Labs, if I believe the stories that I’ve been told, Duo Labs was a pivot, a very important player in some of those early days. Let me continue that thought, I suppose they took those learnings and built these great resources that inspired tons of people, including myself. I directly attribute where I am today as influential and as deep in the WebAuthn space as I am to the WebAuthn.io and WebAuthn.guide. And it’s incredible to have an opportunity to give back in this way and help others appreciate this new technology that’s available to help everyone log in and keep them all safe online.

Charles Edge:
Love that.

Marcus Ransom:
To take things back a little bit, how would you describe what this is trying to achieve for someone who isn’t maybe as deep into the technology as you are? What’s the 30 second pitch for what you’re trying to achieve here?

Matthew Miller:
Oh, boy. I feel like I should be better prepared, but sometimes I’m in the weeds for so long that it’s not often that I have to. Oh, shoot, how do I say this? I wish I had a [inaudible 00:11:58] really one sentence thing for this, but it’s a technology that makes you safer online and is easier to use than a username and a password. And I don’t know, I’m sure some people are rolling their eyes in the community, they’re like, “Come on Matt, this was your opportunity.” But I honestly think trying not to focus on the technical aspects of it, this is a superior replacement to usernames, to passwords in a user experience that is way more streamlined, that sometimes when people use it, it happens so quickly, they’re like, what just happened? There’s no way that’s better than a username and a password. But we’re like, “No, no, it is.”

Marcus Ransom:
So is this going to be the technology that means that my parents’ series of books with all their usernames and passwords written down in them will finally get to go away? Is that sort of hopefully what this will deliver?

Matthew Miller:
I totally think we’ve passed to the inflection point for this technology, because I’ve learned that they’re technically called modalities, but they’re the face ID and touch ID and the pin that you enter into Windows Hello, these are ways of authorizing the secure hardware to authenticate or to respond to authentication requests. And those have become so ubiquitous and people are so used to using them that I really think this has a chance of breaking into the mainstream, especially with the tech. The technologies are out there now. Apple announced their passkey support of, what was it? I wrote a huge, long article about this at-

Tom Bridge:
WWDC?

Matthew Miller:
… May last year. I was at RSA conference last year, and I stayed up to the wee hours of the morning, because after the conference I reviewed the WWDC video about it and I was like, “I got to write about this.” And I just sat down and I typed everything out. Here is what is coming, because it was a huge moment for this API. Like we had this API that you had to like… Yes, you could use the fingerprint sensor on your laptop or you could use security keys, but the moment you lose access to any of that, you’re hosed. You’re gone. Your accounts are gone. And it really comes down to how much does the site going to invest in account recovery mechanisms to get you back in. And that’s its own can of worms.
But the fact of the matter is the user account recovery story was the weakest part of WebAuthn for years, for several years. And if a user cannot survive device loss, their accounts can’t survive that, it’s a no-go for most… I think consumer users is… For the rest of us, the majority of us, and now passkeys come along with this new paradigm where they’re going to synchronize your private keys, which in the security space is like, oh, whoa, that’s awful. But that is exactly what was needed for this technology to have any chance of being adopted by everyone. And so I really think we’re there now. We’re getting there and I’m very excited for the possibilities.

Charles Edge:
It’s interesting that you say that piece about the syncing, because reading through the W3C notes, it seems like the old school, like Fido Alliance types were pretty against that very concept of syncing those keys. So it is worth mentioning that’s why you have to enable iCloud keychain on the Apple side if you’re going to use this technology, et cetera. But on the WebAuthn.io piece, a proof of concept can be about as functional as we want it to be. And there’s two main buttons, and this is why WebAuthn.io is so awesome in my mind. One button is for register and the other button is to authenticate. And when we hit register, we’re creating the passkey. And when we hit authenticate, we’re calling an object that has been created with those calling the navigator.credentials.create and navigator.credentials.getendpoints. Am I fairly solid on this so far?

Matthew Miller:
Yeah, so far so good. I’d say that’s a good way, characterize it.

Charles Edge:
And so the browser has a handler for those JavaScript functions, right?

Matthew Miller:
So WebAuthn is, the API, is something that is implemented by the browser and is offered to client-side JavaScript as a global method. That navigator.credentials is technically the credential manager’s API that WebAuthn adds a type of credential to that, the public key credential. And it’s through that API that, as you mentioned, you call the two methods creator or get.

Charles Edge:
And there’s an ID which kind of semi replaces the username, right?

Matthew Miller:
All right. So like each creden-

Tom Bridge:
Yeah, usernames are tricky and I think that this is where the rubber meets the road for a lot of this, right?

Matthew Miller:
Well, here’s the thing, is the credential ID is not an identity. There is a many-to-one relationship between a user, one to many, I suppose, to a user and the credentials that they have registered to themselves. So the credential ID is not the user ID. And in fact, you specify a user ID when you register a credential, so that can be the same thing. And when you authenticate, some authenticators can remember that and will give you that user ID back, but the credential ID itself is merely just a unique random identifier for this credential that has been created. So I think that’s something worth keeping in mind as we go forward

Charles Edge:
And in the Chrome world, we can then create an extension. And this seems to be the way a lot of people are handling this or use the JavaScript console to see some of what’s going on back and forth and the raw chase JSON that both were presented with and then that were posting to those endpoints, correct?

Matthew Miller:
Yeah, there’s a number of ways that you can sort of peer into all the raw values that are coming and going. A browser extension is one, there’s the dev console, which once you open that up, you can go into the debugger, the scripts tab and essentially set break points. And a good one to set is you do a command F for navigator.credentials.create, set a breakpoint there, run your code, and then the browser will pause before it shows anything WebAuthn related. And you go and you can inspect the options that are going to get sent in and be like, “Okay, here’s the user ID and here’s the username, and oh, they’re specifying such and such value.” So yeah, there’s many ways that you can sort of get a peek at those. Yeah, it’s just whatever you’re comfortable with.

Charles Edge:
And I guess in that JSON blob, for lack of a better word, we see a challenge and off data and I’m sorry, this wasn’t in the show notes, so feel free to skip it, but can you describe what’s kind of happening with those two parameters as they are in relation to the ID maybe?

Matthew Miller:
Sure. So at its most basic a WebAuthn registration or most commonly an authentication is the signing over a challenge that’s been given by the relying party. And I’m going to probably say that relying party RP interchangeably, the relying party in simple terms is just you using WebAuthn. It actually means something a little bit more, but I don’t know if that’s important necessarily, but in this context. So the challenge essentially is the server, the relying party giving to the authenticator, a unique value that the authenticator can sign over a cryptographically with its private key that has been, during the registration process, a key pair is created. The authenticator maintains the private key, and then as part of the registration process, a public key is handed over to the relying party. So on a subsequent authentication, using that credential ID, the relying party can receive back a response from the authenticator, an authentication response, and then look up its public key that it has for that credential and verify the signature and verify with a fairly strong level of assurance that the authenticator that was registered is the same one that’s being used to authenticate.
And so via that credential ID, you could then internally look up, okay, well this credential ID was registered to this user, so we’re going to log them in as this user. And because of the nature of public key cryptography, as long as you can prove you have ownership of the private key and you verify that via the public key, that’s a great authentication mechanism. So that challenge, going back to your question about the challenge, the challenge is unique value that is supposed to be updated on every registration authentication attempt kind of to prevent replay attacks is a great reason for that. So yeah, that’s all. You basically have a bunch of random bites say, “Hey, authenticator, sign this, give it back, verify the signature, log the person in, bing, bang, boom.”
And sorry, so now onto your second question. You asked about authenticator data. Now authenticator data, excuse me. During registration, the authenticator can give back. Well, this is during authentication as well now that I think about it. You get back a collection of information that are things like, I got to look this up real quick, I apologize. I have my code base here with my cliff notes version of things, because there’s a lot of values that are in that authenticator data, and there are various checks that go on too. If you actually look at the spec and you dive into all of these checks and everything that need to go so that a response can be considered valid, very quickly, you’re going to start looking for a third party library to slot in there instead, because it’s just too much complexity. But it’s things like, here is a hash of the RP ID that was associated with… This for IS registration, so the authenticator will hash the RP ID and give it back.
And so then if you’re the relying party, what that RP ID is, for example. So you would have the hash of it yourself, you would compare the two and go, “Okay, yes, this authenticator is responding to a request. That was my RP ID.” There’s one check. Another one was it was the signature, or I’m sorry, was the challenge. Was the challenge the one that we gave you? Sure. And if it wasn’t, then you would reject it and go ahead and move on. There are some interesting flags, was the user present? Was the user verified? Those are very important as you get into multifactor authentication, because just for a second, WebAuthn has essentially three discrete use cases. You can use it for second factor authentication after username and password. You can use it for password list where the user provides a username and so you know what credentials they have registered.
And the third one is, it’s called user nameless, but nobody calls it that. They call it passkeys, because you get to a point where essentially who initiates the authentication kind of flips there. Where in the passkeys world, a user could technically just give a website a credential, and if the authenticator that has the private key for that credential can sign a challenge, then the relying party doesn’t necessarily need to know who the user is ahead of time. So you can kind of skip that username submission step, which is why it kind of gets called user nameless. And we can go into that a little bit later.

Charles Edge:
There is an origin field in the JSON, so if it’s not the right one for that site, then it’s not going to send it, I think, is my understanding of the spec?

Matthew Miller:
Right. So the origin is something that gets reported, but I believe that’s in client data JSON, which yes, so that’s in client data JSON. So you have in the response that comes back from authenticator, technically it’s coming back from the browser to the website, because the response has not only information from the authenticator, but information from the browser as well, because the browser will collect information about that’s the origin. The origin’s probably the most important one. And the type actually too, it will report, there’s a couple different values that WebAuthn.creator. WebAuthn.get, I believe, and those come from the browser. So there’s kind of this mismatch of where this information comes from, but it’s all to paint this stronger picture that this is a valid WebAuthn response.

Charles Edge:
And one of the things I love about the WebAuthn.io and then being able to cross-check it against WebAuthn.guide is there’s these advanced settings. So as a developer, I can change something, rerun my registration and see what changed in the raw JSON. It’s interesting how I feel like this is the most telemetry I’ve had into exactly what’s happening under the hood since I actually understood how [inaudible 00:25:47] worked for the first time. It just feels very like the developers really wanted you, or the spec writers/developers in Nick’s case or someone else, as an example, just wanted other developers to trust what was happening by showing them every step of the process and kind of a tour in a really completely different way. Kind of being able to see the source code of tour and yet then be able to use it and trust what’s happening under the hood, because I can see that source code, if that makes sense. So it’s pretty rad from that perspective, I’d say.

Matthew Miller:
Yeah.

Charles Edge:
One thing that was interesting to me on the Chrome side is these are all Java Scripts. So I can overload a function and as an example, replace navigator.credentials.get with my own function and redirect things. But as you mentioned, since it’s all cryptographically signed, for lack of a better word, on the backend, if I try to do something nefarious, it seems to just always throw a server error. So that’s kind of rad.

Matthew Miller:
Well, I want to clarify there that, so we kind of touched on a couple things here. The browser API that’s available, it can be overloaded, as you said, you can monkey patch in your own custom function that essentially intercepts the request to do whatever you want. And in fact, I don’t know recently if you have checked out oh 1Password’s vision of the Future, I believe it’s called. And their experience that they have their demo site that you can check out, which is very cool, it’s very streamlined, very pleasant sound. I love that. Which is funny thing to say, but I mean it’s little details like that that I think are going to make or break experiences around this space.
But that’s essentially what they’re doing is they have code that their browser extension can overload that method with one where they can intercept, check out the options, see if it’s something that they can handle. And if it is, then they’ll just boot the request over to 1Password to process everything as per the spec, because again, the output of that has to be compatible, because the website that’s going to ultimately verify that response is expecting it to be in a certain format. And so if 1Password tried to do their own thing, well, they wouldn’t be implementing WebAuthn, they would be implementing 1PasswordAuthn. It would be a proprietary thing end to end that would require a much more complicated rollout.

Charles Edge:
Some identity providers have done that.

Matthew Miller:
Yeah, well absolutely. Absolutely. And there’s nothing stopping anybody from doing that. I mean, that’s just the nature of the web. For better for worse, there are opportunities to do things like that. And so yes, you can go in and you can modify these methods and try to futs with them, but if you try to intercept a response because of the nature of cryptographic signatures, if you mess with any of that information, it’s not going to validate. And so yeah, you do get that assurance, a level of protection there, which is peace of mind.

Marcus Ransom:
This week’s episode of the Mac Admins podcast is also brought to you by Kolide. Our sponsor, Kolide has some big news. If you are an Okta user, they can get your entire fleet to a 100% compliance. How? If a device isn’t compliant, the user can’t log into your cloud apps until they’ve fixed the problem. It’s that simple. Kolide patches one of the major holes in zero trust architecture device compliance. Without Kolide IT struggles to solve basic problems like keeping everyone’s OS and browser up to date.
Unsecured devices are logging into your company’s apps because there’s nothing to stop them. Kolide is the only device trust solution that enforces compliance as part of authentication, and it’s built to work seamlessly with Okta. The moment Kolide’s agent detects a problem, it alerts the user and gives them instructions to fix it. If they don’t fix the problem within a set time, they’re blocked. Kolide’s method means fewer support tickets, less frustration, and most importantly, a 100% fleet compliance. Visit Kolide.com/macadminspodcast to learn more or book a demo. That’s K-O-L-I-D-E.com/macadminspodcast. Thanks to Kolide for sponsoring this episode of the Mac Admins Podcast.

Charles Edge:
So that overloading thing seems outright blocked by WebKit based extensions for Safari. Do you know if that requires an entitlement of some kind?

Matthew Miller:
Yeah, that’s a really good question. I’ve done some browser extension work in the past, but nothing specifically targeting Safari. So unfortunately I don’t have a really good answer for you. I did try asking around a little bit, but I wasn’t able to get a real clear answer on that if it’s something that would… That would be-

Charles Edge:
I think it is, because I’ve tried to build an extension to do the same. I built a Chrome extension and we’ll include that in the show notes to just provide a modal to see what’s happening in the backend. And I tried to do the same thing with Safari, but Safari was like, “Oh hell no.” It’s worth mentioning that Safari is, I think since maybe 2019 or 2020, has begun to conform to the Chrome API standards for browser extensions, which Firefox did a few years ago, et cetera. But I think what they maybe did was they saw, oh, well this is a potential place where we don’t want to provide that level of telemetry with passkeys, so we’re just going [inaudible 00:31:52] it and pretend that that’s not a thing which is understandable. And I guess since we did touch on the browsers, Chrome’s stores, its passkeys in its own place, whereas I guess Safari is storing theirs in the keychain.

Matthew Miller:
Yes. So on macOS, that is definitely the case. Chrome, I’m not privy to anything too much specifically about the macOS internals, but my understanding of the current situation is that iCloud keychain doesn’t have programmatic access for third party browsers like Chrome to access the same passkeys that are available in Safari. Yeah. Okay. So that is the case. Sorry.

Tom Bridge:
Yup. That is the case.

Matthew Miller:
I always have a hard time talking about this stuff, because on the one hand I am a user and I’m like, “Hey, that’s great.” I get consistent passkey behavior on Safari across macOS and iOS, but then as a relying party developer building out passwordless Duo, I am the relying party that is subject to the whims of, so to speak, of the operating the platform vendors, which are the ones in control of the operating system that can access the platform authenticators, like Touch ID on your or secure enclave technically, and then also the browser vendors. And so we, on some platforms like macOS, you have this kind of weird bifurcated authentication experience where some credentials are available in one browser and some are available in another browser. Whereas in comparison, if you look at Windows, all the browsers just call Windows Hello. And so it doesn’t matter what browser you’re in, you have access to the same set of credentials. So yeah, macOS is sort of unique in that regard that passkeys are a Safari only thing right now.

Charles Edge:
And I guess they probably argue the developers and I don’t know, I’m not one of their developers, so I hate to put words in their mouth, but they’d probably argue, “Oh, well we’re working on privacy controls and that doesn’t…” Their implications beyond just the public key, private key exchange that’s occurring there that we don’t want to be open to. I don’t know. I guess-

Marcus Ransom:
I’m guessing it’s similar to the issues we’ve seen with a single sign in extension as well where it works beautifully in Safari and less than beautifully in other browsers, but it seems to be evolving-

Tom Bridge:
I think you mean not all in other browsers.

Marcus Ransom:
Yeah, exactly. But we celebrate our browsers other than Safari, and they’re right to exist on the platform, but for the user, it can be challenging. Like myself, I tried to set up passkeys earlier this morning, and when there was that moment, it’s like I have my various Google identities that I use in Chrome, because my feeling is that’s the browser they were designed to work in and then use Safari for other things. And that moment where it’s like, “Oh, this is actually not going to go on my keychain, is it?” Okay, I might need to rethink this workflow.

Tom Bridge:
Well, and I mean as long as those things remain separate, I think that it’s going to make it a adoption of passkeys as primary authentication, not as secondary, because I was going to say I know it here at JumpCloud, we’d obviously support platform authenticators of all kinds as second factors, but not as primary factors. That’s got to change over time. We want to make that, we want to get to the password this future, because I was having a great conversation with my dad today as we looked over at my nine-year-old and realizing that hopefully by the time he enters the workforce, we’re going to have this all figured out and he’s never going to have to type a password at work. And my dad-

Marcus Ransom:
Or a username if he’s really lucky.

Tom Bridge:
I mean, I was going to say none of that. And it’s all just comes back to, “hey, there’s this future where we get to a better space there and we can dream, right?

Matthew Miller:
On that note, I want to take a moment, just a moment to comment on the fact that everybody knows that these rough spots exist. It’s not like we’re trying to paper over them or pretend that we don’t exist in the space, that even the people neck deep in the standards work, know that these rough spots exist. We are in V1 of passkeys right now. They solve predominantly for your Joe’s Bait and Tackle type of website that wants to securely log people in, because they don’t implement 2FA of any kind.
That’s the majority of people are go unprotected by any second factor of any kind at all. And passkeys are an instant win for them in their current form. But yes, there are things about passkeys that are not good, but it is actively being worked on. There is incredible desire at all levels of the spec to improve the experience and it will come with time. So I really want to emphasize this. If you look at passkeys right now and you’re like, “This sucks. I don’t want to scan a QR code every time I sign into this website.” We all know it’s terrible. And when I say we, I mean the working groups and the platform vendors and the OS vendors, and we are actively working to make it so that this is a thing that you want to use, that your parents can use. We want everybody on board with this and so it will come.

Charles Edge:
It’s funny it’s funny that you mentioned QR codes, because that’s the one thing I’ve never minded. I totally trust QR codes for some weird reason, maybe as a programmer because I know what’s happening under the hood there and I’m like, “Oh yeah, I get that.” But I do feel like the onboarding flow, which I think is kind of what you were referencing, Tom, when you were like, “Well, my dad and my kid.” And I feel like that onboarding flow is kind of one of the integral points. And I love that you kind of semi already addressed this, Matt, because there are a few different vendors who have implemented this on their websites and none at all seem to have as clean and onboarding flow as WebAuthn.io. Maybe that’s because they persist user data and I think the WebAuthn.io maybe gets reset every hour, 24 or something.

Matthew Miller:
Yeah, 24 hours. Yeah.

Charles Edge:
Yeah, speak to that. Okay. So as an example though, bestbuy.com has you log in and then add a passkey once you’ve authenticated. So you still have a username and a password, but you can now create a passkey. And then that device, since they’re device centric for their implementation at least, can then log in the future without reauthing. Do you think this will mature as developers get a better understanding and gain access to better frameworks like the ones that you’ve worked on, maybe they were working on a previous version? And do you think that maybe some of the big auth providers, like Auth0 will have a big impact there, I guess?

Matthew Miller:
All right, so let me touch on your first question by saying that we are still in the exploratory phase of what best practices are for passkeys. So websites like Best Buy that make you create an account still with a username and a password before switching over to a passkeys based auth when you do register. But that’s a common middle ground that I am not at all surprised to see out there, because when you have years and years and years of your security models are based around, okay, a person’s going to provide a username and a password and we’re going to do SMS OTP, that is our security model. We have account recovery mechanisms for if the user gets sim jacked and then their account credentials get stolen. And now you have this entirely new authentication method that can do away with passwords with something so fundamental to the login experience.
We don’t even think about passwords anymore, really. It’s like, yes, there’s going to be a username, yes, there will be a password, but now all of a sudden it’s like a record scratch moment where you’re like, “Do we actually need passwords with passkeys?” No, you don’t. You could literally have your entire onboarding could be, for example, not saying this is the best way to do it, but for example, you could say, enter an email address. All right, if your email address has not been registered, we’ll send you a magic link. So then they go off and they check their email, they click a magic link that kicks off a registration, a WebAuthn registration, and they register the device that they’re on and without ever entering a password, that’s all you really need to bootstrap a user’s access on an account. And from that point on, all they need to do is go to the login form, click log in with passkey, and if they have a passkey available, they’ll click it. The whole song and dance will happen underneath the hood. And before they know it, they’re going to get logged in, no passwords.
Yeah. So we will reach some point in time where everyone, lots of the common websites are going to get comfortable with what passkeys are capable of. They will a adapt their authentication experience accordingly. And then as people get used to that, those become the norms that propagate out to the rest of the internet. And this goes then to your second point where a lot of people do use a single sign-on experience. They sign in with Google, they sign in with Facebook, they sign in with whoever, and those, I think you call them identity providers, I think they’re identity-

Charles Edge:
Ish. Identity Adjacent. [inaudible 00:41:47] Yeah, that’s a really good point.

Matthew Miller:
They’re not IDPs in the true sense, but they are lots of people’s identity on very, very many websites. And so those single sign-on providers are also going to be driving a lot of what people start to internalize as the norms of logging in with passkeys. And so we are still probably, I don’t know, two or three years out, if I had to throw numbers on there. Nobody quote me on that please. But yeah, we’re going to get to that point where these norms are going to start to develop. And so then we’ll look back on what Best Buy did or Kayak and PayPal are ones that are brought up as examples, exemplars rather of the passkey registration and signup experience. But even their experiences are going to get polished over time as their users use it, express love or hate for it, and things evolve over time. It’s just the nature of the beast.

Charles Edge:
It’s interesting as a developer, like you quote-unquote “get” authentication and authorization for free when you use Auth0, right? That’s kind of why you pay them that identity tax I guess you could call it. And yet, once the user is actually authenticated, now it’s on me to build all this logic around, you mentioned resetting different factors of credentials or-

Matthew Miller:
Like account recovery in general.

Charles Edge:
Yeah. And some of that you do kind of get for free from Auth0, but to a large degree they’re just handling the OIDC connections or the SAML, or if you’re using Facebook slash the consumer GitHub, it’s weird to think of them as a consumer identity, but you get a lot of that logic for free with them. But yet there’s still a whole bunch of stuff for me to maintain, which as a developer, you’re like, that’s two to three months of just trying to figure out all the different ways that this can go wrong. But yeah.

Matthew Miller:
Well, let me comment on that real quick and I want to ask you this clarifying question. Are you asking about the development overhead or burden maybe of trying to incorporate passkeys into an existing authentication, existing product?

Charles Edge:
Honestly, so as a developer, if I were to take off my admin hat and just wear my developer hat, I would say if we were in a passkey only world, I might not use Auth0 at all, because I get so much for free with the libraries that Duo Labs or WebAuthn.io has already put out there that I don’t even feel like I would need that. It’s a lot of that OIDC overhead and yet how to connect that corporate identity to this becomes a whole other thing that I haven’t even begun to think about. And so I probably would need to pay them, because they would probably think about that because they’re years ahead of anything I might even consider doing, if that makes sense.

Matthew Miller:
It’d be really great if, well for example, if WordPress… Imagine if WordPress the open source project, not the hosted version, but the open source version came with passkey support baked in as an alternative. And you could just say, when you’re setting up your WordPress site, do you want to use passkeys or passwords? No, I want to use passkeys. And from that moment on it’s all set up there. That would be really cool.

Tom Bridge:
Oh, I can’t wait for that mean as someone with more WordPress sites than I’d care to mention. I mean, the podcast runs on WordPress. My blog runs on WordPress.

Charles Edge:
My body.

Tom Bridge:
My foundation… [inaudible 00:45:54]. There’s a lot of WordPress in my life. It also helps that I’m married to a WordPress product manager. And I was going to say the idea of a password free environment is certainly something that I think Matt Mullenweg who’s one of the honchos at WordPress has thought about and I’m really hopeful is part of their near term roadmap if only because… Oh man, the only challenge, and I think that since WordPress is a consumer facing product more than anything else, they’re going to have to nail the account recovery key or the account recovery workflow.
And that, as we’ve mentioned prior, is the hardest thing to do with WebAuthn today. So as we think about this from the perspective of passkeys, generally speaking, when Safari uses a passkey, it requires the biometric on the device, you touch ID to the device or face ID on your iPhone. Chrome requires a user to enter a password instead, the biometric is just a way to have larger passwords to get at the ECC keys that are inside your secure enclave so that are stored on the platform authenticator that secure spot within your environment. So is there more to it than that? I mean, is it actually accessing something along the lines of a derived credential in the FIDO2 sense?

Matthew Miller:
So the interaction of the biometric factor, whether or not that’s face ID, touch ID, the browsers, regardless of whether it’s Safari or Chrome, are all essentially requesting user to authorize the ceremony, to authorize the interaction with the hardware security module, secure enclave on the T2 chip, I think. It’s secure enclave on the T2 as well as on iOS, right?

Tom Bridge:
It’s secure enclave. Yeah, it’s all the secure enclave.

Charles Edge:
They’re all TPMs.

Matthew Miller:
Yeah. So part of that is WebAuthn by design wants to ensure that somebody is there actually authenticating and in the WebAuthn space that’s called user presence. And so the interaction, the physical interaction of the user with a device, whether or not it’s a security key with their little tap target or it is touch ID or face ID, there is some kind of user interaction that has to take place at the bare minimum just to provide that single factor of authentication. That would be something you have. There we go. That’s right. So thank you, something you have. Yeah, so that I think the interacting with the biometric sensor is probably the quickest way to take care of not only user presence, but also user verification, which is the second factor you can get out of it, which is also a requirement for passwordless and for passkey interaction. Is you want to get multiple factors and biometrics is a great way to do it.
It’s interesting that you mentioned that Chrome makes you type in the system password. I’ve had Chrome also prompt me for touch ID. So the experience is largely consistent across both. So it’d be interesting and sometimes in the future to dig into that a little bit. But the fact of the matter is, on any platform, through any browser, when you interact with that, you’re authorizing the HSM to respond on your behalf with the signing of a value, the signing of the challenge rather and how that occurs at the OS level is way beyond me. I have no idea.

Marcus Ransom:
So it’s really to avoid being able to write dreadful API scripts with passkeys in plain text sitting in a script. That’s what the presence is there for to say, “This needs to actually be happening, not just copied in a dreadful script either for someone trying to automate something really badly or for nefarious processes.” That it’s without the person being there, these things just shouldn’t work.

Matthew Miller:
Yep, yep. Yeah, that’s a great way to put it.

Marcus Ransom:
And the passkeys themselves that sit in the keychain or the Chrome database or a password manager, they’re encrypted as well. So they have to be decrypted when they’re used to simplify it or to simplify the explanation of what’s going on.

Matthew Miller:
Like authorizing the communication with the secure enclave, for example, is where the decryption happens? They actually reside encrypted in the secure enclave? That’s interesting to me.

Marcus Ransom:
Or well they’re residing encrypted in the keychain, but the secure enclave is what allows them to be used. Just opening the keychain isn’t enough to get access to these, is that right, Charles?

Charles Edge:
You have to be present, although I think that’s an actual server side option that can be altered based on the site if I’m not mistaken. But yeah, you have to be present. You have to put your finger on the thing to unlock the TPM or if it’s Chrome, it’s basically doing the same thing, but it’s Chrome storing the objects.

Matthew Miller:
Yeah, Chrome has to definitely manage their credential material differently, because again, they don’t have access to any of the passkeys in the iCloud keychain. How Chrome does that, nobody has any doubt that Chrome is protecting them in some way, whether or not it’s in some unsynchronized part of iCloud keychain or something. I’ve never had to dive into that side of things. But this does feel like a great time to dive real briefly into the security passkeys, because I think naturally people are like, “Well these private keys are getting synchronized to multiple devices, how? And how are they protected?” And that’s been a very common question to me anyway. And I want to dive into that just real briefly, because it’s worth answering. Apple has put out a white paper about how they protect passkey private key material in iCloud keychain.
And in addition to needing to be signed in the same iCloud account on multiple devices so that you’re referencing the same iCloud keychain, the passkeys themselves get encrypted before, they get encrypted locally with the local device unlock code before they get sent up into iCloud. And so on another device that has access that you’re signed into with your same iCloud account, they can be synchronized down, the encrypted blob could be synchronized down, and then they can be decrypted locally so that you again have a copy of this on both devices. And that’s really where the account recovery magic is because if you throw your phone into the ocean, you sign into your iCloud account, you have to enter the unlock code of your old device so that your new device can then decrypt the passkey data, re-encrypt it to resend it back up with the new keys from the new phone. And when I say, I mean the encryption keys not the passkeys themselves.

Tom Bridge:
Yeah, and I hadn’t put it together until just now, why you needed to have the password of the other device that’s in there, because that’s also what’s doing your iMessage keys. It’s also what’s doing your iPhoto or library keys. All of those key transactional objects are tied and intermingled directly to the unlocked passwords of your other devices at that point. And so it’s also what happens when, if you can’t sync those things as I recently had happen to my work Apple ID, hilarity can ensue when a new device is brought online.

Charles Edge:
Anytime there’s a larger atomic operation that’s talking to multiple TPMs, it’s going to have to unlock them all, because in general, I think they’re all using ECC keys now to… And so you have to invoke that private key or talk to it in order to be able to put the things in all the places that they need to be. I haven’t actually found that to be, and I guess I’ll have to dig into how this works with Chrome, where if I have Chrome syncing my credentials between four different machines, it doesn’t always tell me, “You have to put your fingerprint here.” And also Chrome actually gives me that option to use a password instead of my biometric information, which I guess I’ll do more research before I open my big mouth about that.

Matthew Miller:
Yeah, and that’s one of the pain points of just WebAuthn in general is sometimes a website like that you’re trying to sign in with a passkey will just… It’ll break. And there are things like, for example, on some corporate environments, iCloud keychain sync is disabled, because the company is just not comfortable with information being stored in a third party cloud and totally valid, totally valid concern. And so they’ll push out MDM policy that will disable iCloud keychain sync, but that doesn’t get reflected in Safari when you go to use a passkey. So all of the API calls will be there going, yes, WebAuthn is available, passkeys are ready for use, and the user will try to use a passkey and it just errors out. And it’s a very confusing time for users, because they’re like, “Well first of all, what the heck? I can’t log in.” And they immediately get frustrated because they just want to log in and go about their day. And so those are the kinds of wrinkles that are going to get ironed out over time.

Marcus Ransom:
It’s going to be interesting to see how long it takes for organizations to jump on board and embrace this. You mentioned before, organizations disabling biometrics, and that’s something that’s really perplexed me talking to organizations about that, “Oh, we need to do a security attestation to decide if touch ID meets our standards.” And Apple’s documentations there and all I can say is that if it doesn’t meet their standards, I’d like to see their standards, because once you read about Touch ID, it’s pretty freaking secure and very well-thought-out. And I think it’s just fear of the unknown. We don’t know what this is, we don’t understand how this works. And I think the more organizations that use that as a prompt to say, “All right, well let’s actually understand the implications of this. Is it going to help prevent our users from using more risky ways of accessing corporate data or accessing personal data on corporate machines? Are we actually opening up attack vectors by not using this?”

Charles Edge:
I’ve seen very few where I’ve used the challenge question, “Well, do you allow Windows Hello?” And they’re like, “Oh, yeah.” And you’re like, “What?”

Marcus Ransom:
Well, it’s Microsoft. It’s better.

Charles Edge:
A TPMs a TPM, right?

Marcus Ransom:
Yeah. But I think if people have known that and have experienced that and have undertaken reviews of it, then they’re comfortable using it. It’s just trying to get them the resourcing and the comfort to investigate other things that may be the same thing just with a different name. But until they can validate that that is in fact the case, the answer will always be no.

Charles Edge:
Well, same things with a different name ish, as Matt alluded earlier, like there’s far more granular controls available for Windows Hello. And it has it’s fully API accessible as opposed to places where the keychain isn’t, or at least the secure enclave via the keychain. Yeah.

Marcus Ransom:
Hearing people, everybody wants to use this at the fall volt unlock window, which would be quite-

Charles Edge:
Well, there is no way of programmatically… It’s a sealed volume.

Marcus Ransom:
Yeah.

Tom Bridge:
This episode of the Mac Admins Podcast is sponsored by dataJAR creators of datajar.mobi, a cloud-based managed MDM solution that redefines Apple device management. Developed from the ground up by Apple admins for Apple admins, datajar.mobi is the first solution to truly extend the capabilities of Jam Pro, the undisputed leader in Apple device management. Datajar.mobi superchargers Jam Pro through a managed MDM service that delivers simplified zero-touch workflows, fully automated patch management, centrally managed EDR, and a scalable multi-tented view with centralized reporting for global and distributed fleets.
Designed to provide IT teams with the best of both worlds, we have developed a true MDM as a service platform for Apple admins that is fully managed and scalable, but can also be controlled through a rich, but simplified web interface. Backed by the unmatched experience of the award-winning dataJAR engineering team, it is no surprise datajar.mobi is consistently ranked in the top 10 highest rated solutions in the G2 grid for mobile device management. Want to learn more? Come and say hi in the dataJAR channel of the Mac Admin Slack or visit us at datajar.co.uk/macadminspodcast. Thanks so much to our friends at dataJAR for sponsoring the Mac Admins Podcast.

Charles Edge:
I do think this is a, man, an interesting place where we’ve mentioned a few different places where the end result is… Well this is young-ish technology. So what kind of future updates do you expect to maybe the WebAuthn protocols themselves?

Matthew Miller:
Sure, I think, so this is coming out of the Google camp. There’s an Android beta out for their credential, what do they call the credential manager API? And what that’s going to allow is third party applications to essentially become passkey providers where they’re going to be able to create and use passkeys on behalf of a user while the overall authentication experience is managed by the operating system. So what you could have is a really interesting future state where, for example, excuse me, one password… Right now, and we’ve talked about earlier, where passkeys generated in Safari on macOS or iOS in the Apple ecosystem, is just to touch on that briefly. I think this might be a great framing thing I’ve been trying out on people is calling them ecosystems where when you’re having conversations around where passkeys can become available, it’s the operating systems that belong to each of the platform vendors.
So Apple’s ecosystem would be iPad iOS, iOS, macOS. And so right now, as we talked about earlier, you can’t have passkeys from the Apple ecosystem and you can’t use them directly on your Android device or Windows, because they just don’t synchronize in that way. But imagine a future state where there are OS level APIs for third parties to integrate themselves with. Officially, these are official, these would be official capabilities at the OS level. And so 1Password you could slot it into, you could slot it into the passkey experience and then after you create it on your iPhone for example, you can immediately turn around and when you have 1Password installed on Windows and if Windows offered something like that, I don’t have any insights into that by the way, but maybe it’s coming, maybe it’s not. But if we imagine this future state where those same APIs that Android is experimenting with are available on Windows as well.
You could have 1Password implement those APIs and then the user could authenticate via Windows Hello, using a passkey stored in 1Password. And it’s the same credential, it’s the same passkey regardless of platform. And because third parties are able to play in this space, they have a little bit more flexibility to try out things like cross ecosystem synchronization. So I think that’s the direction things are going, because password managers aren’t going anywhere. Just like you’re supposed to have a unique username and password for every website, a unique password anyway, every website is going to get a passkey and you’re going to need to manage that somehow.
There are built in tools now. Safari has a built-in passkey management UI that is good. It’s serviceable, it will improve over time. Not to downplay any of the great achievements that that team has pulled off so far, but surely passkey management will in enhanced over time. Oh no, my original point was that we’re going to end up with, I have 900 entries in my 1Password last time I checked and eventually at some point I imagine I’ll have 900 passkeys and you better believe I’m going to use the service that will let me manage those well. And so I think that’s kind of where I think this stuff is going based on everything I know.

Marcus Ransom:
So instead of 900 passwords, we’ll may end up with 900 passkey managers that we then need to manage. So we’ve just moved the problem.

Matthew Miller:
No, no. Wait a minute. Wait a minute. Wait a minute. Hold on. Let me be very clear. I do not see a one-to-one between passkeys in there, because I really hope that’s not the case.

Charles Edge:
Oh goodness. Yeah. And suddenly 1Password stuck. Wait, they’re not public, but you know what I mean. Yeah.

Marcus Ransom:
We encourage people to do a really good job of it, so we never have to experience that reality.

Charles Edge:
Yeah, and I feel like that kind of segues us into this podcast is for Mac Admins and I’ve definitely taken a developer approach to discussing this topic, but it’s important to remember that a lot of the listeners are going to be managing devices who have to consume this new technology. So for people who manage devices en masse, much of this seems like kind of reference implementation stuff like the WebAuth.io. What suggestions would you have for those admins out there on what they need to know and maybe when they need to learn it? If they need to manage how these keys, and they’re not JWTs, but passkeys are stored on devices?

Matthew Miller:
Oh boy. You could spend a whole hour talking about just this.

Charles Edge:
Maybe we will. Yeah.

Matthew Miller:
No, because I think that you’re absolutely right. There is the developer side of it. How do you implement this stuff? What do you store? What’s the good user experience around all of this stuff? And then you do have the other side of it where it’s like, I just need my people to be able to log in and I want that peace of mind that they’re not going to get phished and my entire organization is going to get owned somehow. So I want to emphasize that one of the reasons passkey and WebAuthn in general is so strong an authentication mechanism is because there is what’s called origin binding in play. Where, and this is why WebAuthn credentials and passkeys are phishing resistant, you’ll hear that term a lot, is because if you have a WebAuthn base…
I use WebAuthn and passkeys, I apologize, but if you use a passkey centric authentication system, an attacker cannot send a malicious email to your users with a link going, “Hey Bob, I need you to sign off on this thing.” And they go to a phishing website that for everything except the URL looks identical to a valid website. And if the user then attempts to log in a username and password world, there’s nothing preventing them from typing in their username and password and getting phished.
In a passkeys world. The browser will look at the attacker’s website and go, “I don’t have a passkey for this site. What are you trying to sign in with?” And the user will never have any way of signing into that website to do anything, to authorize anything, to give anything away that an attacker could then turn around and used to attack your system. And that is so strong a defense that everyone should be learning it right now, yesterday. The first thing you do Tuesday, because in the US anyway is a holiday. But the first thing you should do in your next workday is like go in and start learning about this stuff and look at your sign-in providers and see if they offer passkeys and begin experimenting with your rollout. Find those tech-savvy users in your organization. You probably already know them, you have them sitting in some user group somewhere. And start looking at what you can protect with this technology, whether you have to deploy it in-house or turn it on with one of your sign-in providers, I guess. I think the time’s now.

Marcus Ransom:
And have those discussions with the security team about whether they’re comfortable with it now so that if they take some time to get comfortable with it, get them to start using it, that by the time, as you were saying, this becomes a thing where organizations are easily able to do it, your organization is going to be ready for it and on board and part of the solution rather than rushing to catch up.

Matthew Miller:
Like reevaluating your security models in a passkey world is crucial, because the capabilities of this… Even for me, even I’ve spent the last two, three years getting super deep into the stuff and it’s still weird for me to think about signing into things without a username and a password, because it’s so ingrained in all of us, in our way of thinking. And bias is your perception of authentication, and you need to go into passkey with a fresh mind and be willing to question norms that have been established over decades. And once you have those conversations, then you’re in a really good spot to begin leveraging and enjoying the full benefits of passkeys.

Marcus Ransom:
And some areas of IT are allergic to change. There are some folks that still don’t think DNS is a good idea and maybe some days it isn’t. But trying not to be one of those organizations is the key to success and having that great user experience where you’re able to work out how to support these things rather than how to block them. You can enable and let your users get on with doing their jobs, whether that’s developing what the next great security standard is going to be.

Matthew Miller:
And when you’re reevaluating, and this is for the admins again, when you’re reevaluating your security modeling, and because you want to incorporate passkeys, you also need to reevaluate your account recovery flows. Because the nature of cryptographic key pairs is such that if you lose the private key, that’s it.

Marcus Ransom:
It’s gone.

Matthew Miller:
You’re done. There is no way for you to go, “Well, here’s a recovery key to regenerate the key.” None of that exists. You have to build out your capabilities if you don’t already have them,

Marcus Ransom:
Assume they’re going to lose it and have that as part of the beginning process right from the get-go is how to deal with that rather than having to run around in a blind panic afterwards.

Charles Edge:
I do feel like one thing people can do is start asking vendors, because this propagates the technology faster, especially if you have a 100,000 devices, and I know we have a few listeners in that ballpark. But when you start asking vendors, “Oh, when are you going to add passkey support?” That tends to trigger more resources assigned to those kind of projects by product managers.

Marcus Ransom:
And they’re going to go to their product manager and say, “Hey, we got asked about passkeys again, and this time it was from someone with 230,000 devices.”

Charles Edge:
And there aren’t many of those.

Marcus Ransom:
And that’s a way to get a product manager to take notice is to do that. But it also may be the numerous 10,000 devices organizations adding up, whereas they may have been sitting on 95,000 impacted devices until your 10,000 came along. And then all of a sudden the next release notes are, now includes passkey support.

Charles Edge:
A buddy of mine has, he’s a CTO and they have a few hundred thousand devices. And he was telling me recently, “Oh, I don’t look at things until the standards 10 years old.” And I was like, “Well, if you include the FIDO work…” I feel like it’s been meandering through different iterations for a lot longer than the, oh, well this came out at WWDC that a lot of Apple aficionados might kind of center on. It’s like this is much older. And if you go into even smart card stuff, it’s different, but it’s not super different if that makes sense.

Matthew Miller:
Yeah, it’s not radically like a lot of usability improvements and capabilities.

Charles Edge:
The sync thing is super new, I think.

Matthew Miller:
Passkeys understandably makes security conscious organizations a little nervous. But from everything I’ve seen, everyone is doing their best to try and keep the secret, secret and secure. And I do think it’s a great time to start investing and learning about it.

Charles Edge:
Yeah, and they’re derived. It’s not like you have a password sitting in a vault. And if we’re not going to mince words about it, all of those local vaults are just encrypted SQLite databases, whether it’s 1Password or NordPass or Keychain. They’re all just an encrypted SQLite database. And there are known design patterns to attack those specifically as opposed to this new methodology where it’s like, “Oh, we’re going to use derived credentials and we’re going to change the challenge every single time it’s submitted…” Everything that’s old is new again or whatever. But this feels like a generational shift, like how SAML felt when I first saw it. I didn’t feel that way about OIDC, because I’d already used SAML, if that makes sense. But this does feel like the next generation.

Tom Bridge:
Here at the Mac Admins Podcast, we want to say a special thank you to all of our Patreon backers. The following people are to be recognized for their incredible generosity. Stu Baka, thank you. Adam Selbi, thank you. Nate Walk, thank you. Michael Tsi, thank you. Rick Goodie, thank you. Mike Boylan, you know it, thank you. Melvin Vives, thank you. Bill Stites, thank you. Anush Storville, thank you. Jeffrey Compton, M. Marsh, Stu McDonald, Hamlin Crusin, Adam Berg, thank you. AJ Petrepka, thank you. James Straseet, Tim Perfit of Tucanos, thank you. Nate Sinal, Will O’Neill, Seb Nash, the folks at Command Control Power, Steven Weinstein, Chet Swarthout, Daniel McLoughlin, Justin Holt, Bill Smith and Weldon Dod, thank you all so much and remember that you can back us if you just all head out to patreon.com/mac.admpodcast. Thanks, everybody.

Charles Edge:
But we’ve gone on long enough and we have a bonus question and I never asking them, because I typically write them. So Marcus-

Marcus Ransom:
I’ll ask it. So before we started recording, we’d noticed your phenomenal background that you’ve got on the Zoom. We used to be able to see each other while we would record. You said you hadn’t been to Maxis admin in Goffenberg where Charles and I first met, where bananas are a big thing. So your background is bananas, as we can say. We are used to what bananas mean at Maxis admin, and most of our listeners will understand that. But can you tell us more about why you appear to have, and we’ll put a photo in the show notes as well, why you appear to have many bananas suspended above you?

Matthew Miller:
Sure. So I’m a SoCal native and the last few years I lived in LA County and LA County has lots of a tremendous food and art scene and tons of museums, including these pop-up museums that show up from time to time, kind of like an Instagram experience type of experience, for lack of a better word. Anyway, there’s one called Museum of Ice Cream that popped up several years back, and you go in there and it’s an art installation through and through all these different rooms have all these different ice cream themed motifs. And one of these rooms was, you walk into it, it’s two rooms side by side, one yellow, one pink, and it’s the color of the bananas that are hanging down from color coated or color matching strings in an otherwise white room. It’s very surreal. Totally my thing.
So I don’t even really know why I decided to do this, but I looked up and I took a photo of all of these bananas that were hanging over me and it kind of gave me this vibe of, in the Matrix when they’re standing in the Matrix, that clear white space and they’re like, “I need guns, lots of guns.” They go… They shoot by you. And this just, when you look at it’s like, “I need bananas, lots of bananas…” And all the bananas fly by you. And so something about it stuck with me. The surreality of it was such that I’ve been using it as my video chat background professionally and personally for many years, because it is so iconic. It gets people to remember me and yeah, I will continue to do so until people stop commenting on it.

Charles Edge:
What you’re saying is bananas are memorable.

Matthew Miller:
Oh, is that a thing that I would’ve got if I’d been to Maxis admin?

Charles Edge:
I don’t know. Yeah. We might have to have a guest on just to remind us where the Maxis admin banana thing came from, because I’m getting old and I don’t really remember.

Marcus Ransom:
I seem to recall somebody found out when, I think they were on one of the canal boat trips or something like that. I don’t know if it was Eric Dreyer or somebody else that somebody mentioned in passing that Sweden has the largest per capita consumption of bananas in the world. And so that’s my understanding where it came from. But it’s more about where it’s gone to rather than where it came from is the bit that I always enjoy seeing random bananas pop up in all the presentations. So game on for this year, Charles.

Charles Edge:
And the Slack channel, people will walk by random banana things and drop them in there, or if it’s Jagermeister, they’ll drop it on my Facebook feed. And I’m trying to explain that to the kids, but having a hard time doing so. But yeah.

Matthew Miller:
Yeah, I wanted to thank you for the opportunity to talk about passkeys at length. I love evangelizing the technology, because I believe strongly in it and there’s tons of resources out there. And I want to call out passkeys.dev real quick. Myself and Tim Kapali at Microsoft, we’ve put a lot of effort into trying to offer a single place for somebody to go to and learn well, what the heck is a passkey and how do I use them? And so there are great resources out there. And yeah, thanks for having me on here. It was really good time.

Charles Edge:
It’s a pretty website by the way. I’ve actually been to that one and the use of flat graphics. I’ve become a big fan of just like, oh, what I need to know when I need to know it real fast.

Matthew Miller:
[inaudible 01:19:13] of beauty.

Charles Edge:
Yeah, so thank you for not only that, but WebAuthn.io and .guide and all of those contributions. I have to say, this is one of the technologies that was quite possibly as a developer/product manager, you have these moments where you’re like, “Okay, this is going to take me four cycles,” whatever cycle means to you, a two week, whatever, everybody has their own definitions of these. But this is going to take me X number of cycles. And then you get into it and you’re like, “Wow, that took me a week,” with full testing and unit testing and all the different things like, oh, I’ve got this. That was because the people who built this, you, et cetera, have done the work to make it that way. And that was much appreciated. And I also feel like, as I said earlier, I felt like I had more telemetry into what was happening on the back end, just being able to watch each step of the transaction and more trust also at the same time, which isn’t always synonymous, if that makes sense.
Sometimes you’re like, “Oh, wow, the more telemetry I have, the less I trust it.” Whereas with this, I was like, “Oh yeah.” And I kept poking at different angles trying to figure out the next black-out talk or whatever, and you’re like, “Yeah, it feels like they’ve got a lot of bases covered here.” Apple released it when they did or released their implementation of it when they did, but it’s not that young. It’s far more mature than it would seem as, oh this was talked about at last WWDC for the first time and the developers that talked about it at WWDC did a great job at their reference implementations. Not saying anything there, but it is definitely far more mature than it comes across, I think.

Marcus Ransom:
Also, from the admins perspective as well, I think from being able to explain what’s going on and most importantly why those things are going on, I know has made me feel a lot more comfortable about how well-thought-out this is and how close to being widespread it’s likely to be. So you’ve given a really great insight into how much work has gone into this and how much thought has gone into this. So thanks very much for agreeing to spend some time with us.

Matthew Miller:
Oh, I was going to say, there was a lot of… about TPMs ending up on everyone’s devices on the early 2000s, was going to be the downfall of open computing. Now, I don’t know, that may have come to pass if you wide vine and stuff like that, DRM. But it’s also established a very strong foundation for a great authentication alternative, because without a secure enclave on every Apple device, you wouldn’t have WebAuthn, you wouldn’t have passkeys. And so very thankful for that.

Marcus Ransom:
That’s awesome. So folks want to find you on the internet, where can they go looking for what you’re working on now and what you’re working on next?

Matthew Miller:
Sure. I recently moved over to Mastodon more or less full-time. So I am, iamkale@infosec.exchange and I’m on GitHub as MasterKale, all one word. If you go to simpleWebAuthn.dev, that’s my personal WebAuthn library. You can track me down over there, Millerti.me, is me as well. I have a blog that I maintain where I post a lot of stuff about WebAuthn deep dives on, for example, I just posted recently about how to use the pseudo random function extension coming to WebAuthn to encrypt, to perform end-to-end encryption entirely in the browser for good or bad.

Marcus Ransom:
Well, thanks very much to our sponsors this week. It’s Kandji, Kolide, dataJAR, and to [inaudible 01:23:49] for sponsoring the transcription of this episode this week. Thanks to our Patreon subscribers and thanks to all of you for listening. So we look forward to seeing you next time.

Speaker 6:
The Macadmins Podcast is a production of Macadmins Podcast, LLC. Our producer is Tom Bridge. Our sound editor and Mixing engineer is James Smith. Our theme music was produced by Adam Kodiga the first time he opened GarageBand. Sponsorship for the Macadmins Podcast is provided by the macadmins.org Slack, where you can join thousands of Macadmins in a free Slack instance. Visit macadmins.org. And also by Technical Evolutionary, LLC. Technically, we can help. For more information about this podcast and other broadcasts like it, please visit podcast.macadmins.org. Since we’ve converted this podcast to APFS, the funny metadata joke is at the end.