What is a passkey and why should you care?

David:
00:00:02
Hello and welcome to Android Bites, powered by Esper. I'm your sometimes host David Ruddick. And some weeks I'm joined by my co-host Michelle Ramen, who really is the, the brains behind this show. I'm more just a talking head. This week we've got some really great folks on to talk about a topic that, honestly, I know nothing

Tim:
00:00:21
about

David:
00:00:22
PA

Tim:
00:00:23
Keys.

David:
00:00:23
I'm really interested to learn. And Michelle, would you like

Tim:
00:00:26
to introduce our guests?

Mishaal:
00:00:27
Thanks David. So on today's episode, we invited Tim Capal and Chris John Brand. And I wanted to give you guys, both the opportunity to, introduce yourselves. Like what company do you work for? What exactly do you do? And how much do you know about Paske? Like, why are you two the Paske guys? So why don't you go ahead, Tim

Tim:
00:00:45
or Christian?

Christiaan:
00:00:45
Yeah, go ahead. I'm happy to go first. All right. Hi folks. I'm Christian brand. I'm a product manager here at Google. I've been working on, fighter related initiatives here at Google for. Probably a little bit over 70 years, so far. And before I came to Google, I had a startup and we were also part of the Fido Alliance and working there even before I formally joined Google. So I have been, in this space for quite some time. our goal was always to bring this technology to the masses, which really is what PAs Keys is all about. And when I say this technology, I'm talking about the technology that, we've together with a bunch of other companies, Tim from Microsoft here, will tell you a lot more about their, perspective on this as well. But, essentially there is a whole bunch of companies part of this thing called the Fido Alliance, Microsoft, the third Apple is there, Google is there a whole bunch of other companies as well. We've been working in this space for four years. But the technology was niche. It was for users who had very specific types of hardware called Fido, security keys, and other types of technologies. and with past, we are really bringing that technology to everyone and making everyone online safer.

Tim:
00:01:49
Thanks, Egen. Yeah. Hi everyone. My name is Tim Capal. And I work at Microsoft as a standards architect. So I actually work heavily in the Fido Alliance with Christian and with Google as a partner as well. And also a lot of this technology is also designed in the w3c, So that's where a lot of the browser components come into play. I joined Microsoft smack d in the middle of Covid March, 2020 when the world was shutting down. And so before that, I actually worked in network identity, So wifi network wifi, roaming, wifi identity, all that fun stuff. And I've had a passion for wanting to kill passwords since I kind of started that journey. So, made some progress on the network side, right? There's still, some things that need to be done there, but was super excited to start working on this problem at Microsoft as well, albeit at a different layer, on the web for apps. But similar problems exist, passwords are one of the top problems with. All, all, all cyber security issues these days. So, super, super excited to collaborate with Google and Apple and the vital alliance on this whole pasky thing.

David:
00:02:44
Yeah, my passion for killing passwords, I have never seen it put so eloquently. I

Tim:
00:02:49
love it. So, yeah, I had a nickname. The customers at my last job gave me the nickname TLS Tim, because the solution on the network side for not using passwords is TLS certificates. And I got a little worked up when I was talking about it as usual, like, let's kill the passwords. And so now my new nickname, I was coined on Twitter as Tim Kaki. So there's always some nickname somewhere. Nice.

Mishaal:
00:03:10
So I think we all have a general good understanding of why we want to kill passwords, among us but some people may not be as on board or it might be as familiar with why you want to go ahead and do this. So you want to convince people to switch away from the password, you need to convince them that whatever you're building, the alternative is better in every way. It has to be not only safer, it has to be as convenient, if not more convenient, and it also has to be, easy to understand and use. Why don't you just start off by telling us what exactly is wrong with passwords, what makes them inherently more insecure than whatever you're working towards right

Christiaan:
00:03:41
now? I'll jump in. I mean, so, so many things wrong with passwords, right? There are shared secrets for one, You know, Your password, the site on the other side also essentially knows your password. Yeah. Maybe they have a hash, whatever, right? But these hashes are not always that hard to reverse, and there is a whole bunch of reasons why passwords as a shared secret model has limits on what you can achieve from a security perspective, if that other end of your password gets breached, Let's say I use a password ABC one q3, right? And I use it on website X. If website X gets breached, now everyone knows my password. If I then went and I reused ABC 1 23 across various websites, Let's be honest, most users do, or at least until password managers became a thing, that was what everyone did, right? So now it means that when your password on website X is breached, your password is breached everywhere, Because it's essentially the same password that you keep reusing with the same username, password combo. So, remote end breaches, big problem with passwords password reuse, giant issue there. And then of course, my favorite thing to hate about passwords. They're super easy to fish. And I think that has really been what at Google we've been interested in solving ever since we started on this journey, right? Our journey of the Fighting Alliance didn't start because we wanted to kill the password. It started because we wanted to kill fishing. Back in 2009. A bunch of, tech companies, Google being one of them was subject to the Operation Aurora Hacks, which, By this point, it's pretty public. and how all that started again is kind of like with Phish, right? Because usually these attacks start with Phish. We wanted to solve that problem. We still, we want to solve that problem. the technical solution to this was essentially what became the PHY two F standard. We first implemented it internally for our own workforce and then we wanted to implement it for our users. And then at some point we decided, well, if we now have five B, two F and we've essentially solved phishing, what are we even doing with passwords any longer? Can't we just get rid of them too? And I think that is then. Microsoft joined the FI alliance, I think it was back in 2015. Tim can tell the story from there on out, but really at that point it was like, why are we even doing passwords? Can we just stop doing passwords and simply rely on the technology that we now have in FI Alliance? which essentially gets us now from like I said earlier on, a niche solution into the mainstream consumer solution. Because for mainstream consumer solution, you can't talk about, oh, this is a lot more secure and oh, this sells fishing. You need to talk about convenience. This needs to be simpler, it needs to be easier to use. It needs to be faster. And that is, I think, what we finally have with the current set of standards, which essentially collectively we call Paki uh, over to 10 because I'm short term, have a lot more to, to talk.

Tim:
00:06:21
No, I, I think one of the big changes that happened since, Christian talked about rolling U two F out to Google is that pretty much every device that CHIPS now has biometrics, and a secure element and all these pieces that you couldn't weave a story together for both a user experience standpoint and from a security standpoint across the board, There was all this fragmentation. So we're now at the point where even low end devices have pretty high security capabilities compared to even five years ago, So the fact that if someone with a $2,000 phone and a $500 phone can all securely log in online using either biometrics or device pin is game changing, right?, that is why the time is now because we just didn't have that luxury. On the enterprise side, Security keys with a thing, right?? The little, USB or NFC dongle. And that has cost and users lose them and users don't understand them and there's no good name for them, All these things that compound to the point where it's just another annoying thing that it gives you that you have to carry and use. And the most ironic part about the security key thing nowadays is like everything else that's on my key chain is, either on my phone now or moving to my phone. The only thing I have left on my key chain, I have a security key, but I'm a nerd, so let's wipe that out. But my mailbox key, that's the only thing that's like analog and on a key chain. So telling users to secure their digital life, you have to carry this thing on your key chain. that's a hard sell, especially from all these same companies that are working to give them digital access to the same credentials on their phone. I love your

David:
00:07:43
philosophy about de keying your entire life. I'm all about it.

Mishaal:
00:07:47
there's varying, varying degrees of how closely people follow best practices or what people say is best practices for securing your online life. Do you use multifactor authentication? Like what kind of multifactor authentication do you use? SMS based, app based, security key, et cetera. And biometric authentication, all of these seem like they're just larger and larger. Band-aids being applied on top of the foundation that was, inherently insecure, password based authentication as a primary. And now pasky seems like you're ripping all those band-aids off and saying, okay, let's restructure everything from the beginning. let's rethink completely how we think about primary authentication and start from a more secure model from the ground.

Tim:
00:08:26
Is that like,

Christiaan:
00:08:28
I think that that's the whole point, right? At some point, like I think up until maybe, I don't know, 2005, 2006, whatever, like passwords were okay, right? We all had the same password in which we typed in and things were okay. Then we started introducing password complexity requirements. Then we started introducing password rotations. Then we started to implement multifactor on top of this, It really became unbearable, right? To sign into something new. Every time I have to create a new account, which nowadays you have to do for everything online, even. Technically shouldn't even need an account you end up creating an account every time I have to pick in your password. And it, really is just so frustrating, not because of how password used to be, but what passwords have become. is, it is so cumbersome to deal with them. and has happened with the bandaid? It made the usability of passwords worse and worse and worse and worse to a point where, most of these, I I look at some family members here who deal with online account, their strategy is to bang some numbers on the keyboard whenever they need to create a new account. And then when they need to resign in, they go through the password reset email link because that's the only way that makes sense to them. And I think if that's where we are that's really a broken place. So,, we really need to reinvent that. And yes, you're absolutely right. Paske is a, from the ground of, rearchitecting of how authentication on the web is supposed to.

Tim:
00:09:42
Right. the Goal is that we hope this is the new default credential for the web, This is the minimum bar. Now, if you want to do other things, because for whatever reason as a, if you wanna use a security GI user, go for it. But we need a base level credential that my mother can use. Everyone I know can use that has reliable and consistent across platforms and works across platforms, That's one of the biggest core things we did with this is that this works across platforms, right? It can't be, this only works with Apple and only with Google and only with Microsoft because one of the challenges that we had, like those middle ground was okay, we had passwords that were great, and then we actually started to see more and more of these devices with biometric centers and tpms and secure elements, all these great security features. When the user got a new device, they had to default back to a password, So we, had actually all the pieces, we had everything out there, but we needed to pull it together into a story that was more password like, while having all of the best security properties of this newer phyto technology, right? So that's really what PAs keys gets us. If we think about passwords being a one and, this state for the past few years where all these devices have the capability as 50, we're getting to a hundred now where you can actually truly no longer have a password on an account, You don't need the password to set up your new device because all of your past keys are available all the time with you across your devices and et cetera, that was the missing piece. and that's what PAs keys bring to us,

Mishaal:
00:10:59
right? And part of. challenge now from migrating from passwords to past keys is that everyone knows what passwords are. They understand how they work cause they've been around for so long. I've had trouble getting my dad to use a password manager to try something new because, it's something new. They don't really like using it. A lot of them have sticky notes still, with their passwords are a little notepad. So, paske are entirely new concept and there's not really much, until that announcement that happened back in May from the Fido Alliance, I didn't really know what it was. I hadn't even heard of it until then. And I'm,, guessing a lot of people, even in the tech industry had no idea this was actually going on because a lot of the work was being done through these standards bodies and behind the scenes with all these technical meetings that like you both were probably extensively part of. So, I wanted to get everyone on the same page and go through some definition. So, we really understand. What the heck PAs actually are. You brought this up before Christian, but can you explain what is the Phyto

Christiaan:
00:11:49
Alliance? Right. Happy to do that. Yeah. So, the Phyto Alliance is essentially a consortium. It is a group of companies who came together with a goal in mind. And the goal that we had in mind was simplify and strengthen authentication. That was ultimately the goal. Originally it started primarily like I said, because of certain. Issues that was prevalent even in multifactor authentication, Even if you have an account that's secured with a user MF password and, I don't know, push based MFA or SMS based MFA or even the, ad based MFA where you have a little code in Google Authenticator or Microsoft Authenticator that gets generated technically those types of authentication mechanisms are still feasible. If you have a bad guy sitting in the middle somewhere and they can trick you into typing your password into their. They can probably trick you into typing your OTP coding there as well. And we've seen these types of attacks in the wild. So multifactor authentication as it stands today is no match for a SP fisher for someone who's really after your particular account. And actually it's become easier and easier to conduct these attacks at scale. There is tools out there and X is one particular I think great example or bad example. I dunno. It depends on which way you go of a reverse proxy that is set up to steal credentials, Very, very easily. You can do it at scale. And pretty much deployed MFA technologies are susceptible. Fighter Alliance was set up to develop the next generation of MFA that would not be susceptible to these types of phishing attacks. Started with a second factor. It started with a physical thing called the security key. Then that became, well, why don't we try and build these things into phones? And then the last step was, well, if we actually want adoption here we're gonna have to make this easy. And the companies that joined up in the FI alliance, I mean, this didn't happen overnight. There was a bunch of companies in there. Google joined about a, I think about a here or a couple of months after Fi Alliance inception, Microsoft joined later on, and then again, a couple of years later, we and Apple also joined. We have many, many other member companies. That's more what we call in, Fido language relying parties, those who be your meta, It would be your sales force sap, like the typical companies who would use the te. You also, of course, for anything like this to really succeed, you need the platform providers. The folks who provide the computing platforms, which user users, and roughly those are Microsoft Windows, Android Operating System, iOS, Mac Os, Those are the places where users are. Of course, there are other as well, But these are the main operating systems that users find themselves on. You want this technology baked into the platforms directly. You don't want to have to have users go download things and figure out how to set stuff up. This just needs to be secure by default, It needs to be built into the platform. It needs to be there. And one point that you made earlier is how do we even explain this to users? That's the cool thing about the way that this is architected. You don't really have to. The goal with Fido and with Paki are when the user uses their application in the way that they use it today you can surface the user a prompt and say, Hey, you used to be signing in, using passwords. Do you just wanna use your face next time or your. That's all you really have to ask the user. Now, the cool thing is, ever since the advent of the iPhone 5S users have become accustomed to using biometrics to log into apps. I mean, if you have a banking app on your iPhone today, chances are when you open that app up, you're gonna supply your face or touch your fingerprint, That is where we start with PAs keys. We then do a whole bunch of things a little bit better than the, status quo. Because when you get a new device, passkey continue to work. You don't have to fall back through passwords. When you wanna sign in on another device that doesn't have a passkey on it, you can use your phone that has your passkey in some wireless capacity in order to allow that device to sign in as well. So lots of additional flows gets enabled, but users don't need to know how PAs work and necessarily what they are to use them. We try to meet users where they are. We try to meet them at the point where, I just signed into my app using my fingerprints. That is exactly what PSS are and more. Right.

Mishaal:
00:15:47
I do understand the goal and that's part of what makes it as convenient, if not more convenient than passwords. The fact that users don't really have to know the underlying technology at all. But I do still think it's interesting to talk about, what has to be implemented by, website developers and platform developers such as, Google, Microsoft. So, some of the other terms that have come up, when you search or when you read up on PA keys are the web authentication api or in the client to authenticator protocol, the 5 0 2 project. can you explain what each of these are, who has to implement them or utilize them and so on?

Tim:
00:16:18
Yeah, absolutely. And the reason that there's actually two different things, Wen and Ctap, you, you expanded already is actually to divide the labor a little bit, The nice thing is a lot of the complexity in these protocols is actually handled by the platform or the client, So that's browsers and, operating systems, for example, the operating system is typically what interacts with other devices like a security key or even your phone in the case of interacting with a desktop operating system, That's something as eBay, as PayPal, as any of these web properties or, app based solutions. You don't have to worry about all that complexity, The only thing you actually have to worry about is. A JavaScript api, which is called Web A, which is short for web authentication. And that's, really the primary entry point for a website to request a signature. Which is ultimately what the goal is, Is to get a signature back from a credential that lives on the device or on the other device. And the nice thing is like an eBay or a PayPal as the website don't necessarily need to worry about where it is, It could be on a security key, it could be on a remote phone, it could be on the local device all of that plumbing and even routing is all handled by the underlying platform, So ctap is an incredibly complicated protocol. I'm not gonna sugarcoat that, but only a few, companies really need to actually implement it, which is great, it removes so much of the developer complexity. for services. The only difference really between a website and an app is generally what happens is the operating systems where the apps run, The app platforms try to mirror the browser API as closely as possible, So it, is a little bit different if you're a web developer versus a Android app developer, There's different functions you have to call. Obviously one is native code. But what you'll find if you look at some of the developer documentation is that most of them mirror the web API as closely as possible and translate it into the native context, if you're familiar with the web API and you're familiar with the native language on Android, it's a pretty quick, pick up for a develop.

Mishaal:
00:18:02
And then onto the, topic of the day itself, pass keys. So from what I understand, pass keys is the marketing name for Fido credentials. Can we actually talk about what exactly is a Fido credential? How is it created and stored using, say Android or Windows as an example? Yeah. Do you want, can we, should we talk about the term real quick? Just the people? Yeah. Talk about the term. Yeah. So, the interesting thing about PAs keys obviously it's a play on We needed something that we think over time users will pick up, Like, what the hell does Bluetooth mean? Bluetooth didn't actually mean anything, but people heard it and used it and it caught on. We think passkey actually, if a user has no context over time and they constantly see like, oh, I'm unlocking with my face, I'm unlocking with my fingerprint. and I saw this term passkey, we truly believe that that will stick and that will just become the common term to the point where we also, phyto Alliance introduced an icon you've probably seen as a little person with a key that we hope that eventually, let's say five years from now, users see that and they know exactly what to expect, And really the goal is that when you see that icon or you see the word passkey and you tap it, the user expects to get some kind of biometric, prompt, or selection screen, that is really the goal. And that's all we can really ask for from relying party developers We want you to have either this autofill UI thing, which we can talk about later, or a button that's assigning with the pasky, with the icon, and away you go, No more worrying about should I put windows? Hello? Should I put touch, id, should I put face Id the goal is to have a very neutral term. I've actually since day one been thinking about this in the same way that, a payment terminal. Most users nowadays tend to recognize the tap to pay icon, They kind of like, okay, I can tap my car to my phone regardless of whether says Apple Pay or Google Pay or Samsung Pay. Most users recognize, including my mother, which my mom is a great test for all this stuff. So, that was kind of the thinking with the icon. Can we get to something similar on the web where users just see this and they know they can get in, in a certain way? And Obviously we're very early days here The term is definitely caught on almost faster than we would like in some cases. And the icon we're starting to see relying parties use it. You'll start to see it across the platforms. know, You'll certainly see it in Windows at some point. And variations of it being used in apple and Google platforms. So, that was kind of the thinking. Now that's kind of the end user story, I think, where things tend to get complicated, Twitter is a big, in many cases, a vacuum of tech people, With which sometimes we're, having our own our own debates with ourselves. When you start getting into, technical folks, We can describe past key or past keys as two buckets, One is just the credential type, It's this name of this thing that you use to sign in. And that's how we generically refer to it. We say pass keys or a pass key, We're trying not to say passkey by itself, cuz it's is not a protocol by itself. it's just another name for. The credential. But then when we talk about all these new things that Christian touched on, these other experiences we brought along to make PAs keys easier to use, like the AutoFi ui there's a bunch of things we've done including the cross device authentication. We've kind of casually also referred to that as PAs keys, As an experience. and so maybe it's our own fault for of using it so casually, but we've generally been trying now to say like, oh, you support the full pasky experience and that means the user does not have to have a password at all. You allow them to solely sign up and sign in with a pass key. You're supporting the auto fill ui. Which is a, very easy to implement, which causes the little thing to auto pop up in username field and that you're not restricting cross device or those other things, and ideally we would love you to use the term and use the icon, So those the three things that make up what we call the past key experience which again, we just freely used there. There was never really a good name. There was never a good way to split those up, into what makes this whole picture versus the credential name. So we ended up in this little area, but I think now we're able to kind of differentiate when we're, talking about it. Yeah, I did notice that while I was going through the documentation it's used interchangeably, whereas in one sense you're talking about the private key, public key combo as a pass key and then also the whole process, the cross device authentication. And the multi device Fido credential experience, all of that is encompassing the past key, And so it was a little confusing at first, but I think there's some excellent documentation that really helps, disambiguate what's going on here? So I kinda have to talk about now about the experience of creating and storing a passkey. So, as I just mentioned, when you generate a passkey on a device, say you have an Android phone, you go to a website on Chrome that supports pass keys and you generate a passkey, what exactly is being created, what's stored on your device and what potentially could be synced to say Google Password Manager?

Christiaan:
00:22:17
Great. how did you take that one? So essentially a pasky consists of a record which has some metadata associated with it. and that's really important and we'll talk about that in, just a second, but, Historic password in a password manager essentially is all based on heuristics, There is a password there. There is usually a username associated with that password because that's just how we use passwords. It's this combo of username, password. And that's what password managers know s are a little bit different. When a website wants to create a pasky for a particular account on that website it sends a bunch of metadata to the system in order to create this pasky first. It sends some kind of like a we call it the, old style of user name, right? And this is mainly there because for a while there websites are probably gonna need you support users coming in with both user and password combinations and PAs, you might be logging in from a, I don't know, Samsung television, which doesn't support pasky yet, or whatever the case might be. So for a given account users will probably have to live in this world where passwords and PAs coexist. So, The first thing that the website needs to tell the system or the app needs to tell the system to create a PAs is what's the account name that's associated with this particular pasky. And that could usually be what we call the username. So usually an email address doesn't have to be, but that's kind of like the first thing you're pausing. Then there is also a friendly display name that now exists, which you can pass in. For example, my Google account, I have a Google email address. I have a display name associated with that account. When I tried to sign into Google Google tells me, hello Christian brand with a space in between with a nice capital C and a capital B. And then my email address is shown. Underneath, almost like, it's kinda subservient to this main display name. That's all information that you can pass in when you create a pass key. There is other types of information that you can also pass in as a developer kind of like a handle to this particular credential. If, you need a way to associate that, this will not be displayed to the user. The display name and the username are things that the user will see. And then the spec, there's also the provision for a icon or a picture. if I wanna sign to my Google account and I have multiple accounts, Google will show me. Display name, username, and a little profile picture for each of my accounts that I have. We wanted to mimic that over in Pasky Land. So Pasky technically have the ability to show the user a display name, a username, and a nice little icon. The I Icon isn't yet implemented. It, used to be in the spec. Something's changed, but that's something that we're thinking about in the future. But for now, if you're a developer, you want to passing display name, you want to passing the username. And essentially then once you pass that in, you get. A public key, That is the thing that you now keep on your side. And remember, early on in the podcast, we spoke about how passwords are bad because they're symmetric secrets. PAs keys are great because they're not symmetric secrets. They're asymmetric in nature, which means the public key, which you as the website now keep that you can use to mathematically prove that the user had the corresponding private key, which is essentially what the PAs key is. The PAs key is a private cryptographic key that's stored on your device, which is generated during passkey creation. You now have that private key. Public key is what the website keeps in order to validate in the future that the user still has access to their private key. But the private key never actually gets sent to the website. The website only knows the public key. If something bad were to happen at that website and all the public keys were to leak out, nothing bad happens, right? Public keys get leaked out. They're public, they're called public keys for a reason. there's nothing that someone can do with those public keys directly because the private key is what you would use to essentially, confirm that you have the private key in place, That you have access to this particular credential. So power key is display line, user name, private key, which is on the device, and then the public key, which you send to the service. And then what happens? With PAs, unlike with old style fighter credentials, these PAs keys that you now have on your phone, they're so valuable that we decided that we just have to back them up for you. We don't want to leave them just on your one device, because inevitably you're gonna buy a new phone, or your phone is gonna break, or you're gonna lose it, and you're gonna have to, grab a new one. And what happens to all your pakis, In the old school way of thinking about biometrics, the answer was, well, it's easy. We just have the user fall back to their user M and their password, their m. We don't want that for Paske. We want the user who up Stepss into the world of PAKEs to stay there, never inheriting to fall back to passwords unless they're on a device and don't support PAs keys. But I mean, that problem will hopefully go away over time. So the thinking is like we take your pasky, we then back it up to whatever password manager you use. In the case of Google's, the Google password manager. PAs keys are end-to-end encrypted. So although they're backed up to the Google Cloud, Google actually never learns your PAs key. We can't decrypt it. The only thing we do is we store this encrypted blog for you. And if you show up on a new device and you can prove to us that it's still you by signing into your Google account and perhaps performing an additional ceremony for PAs keys in particular, you have to both have access to the Google account and you have to know the lock screen, how you unlock your previous phone that you had the pasky on. If you can do all of that, we'll decry the pasky locally for you on your Android device and then you can continue where you left off. So yes, these things are encrypted. There is metadata associated and I'll say the last thing on this. The reason why there is metadata associated with it is when you go to a website and you wanna sign in there and you don't know whether you have a paske, you can't remember, like who knows what they used last time that they signed into a particular website, When you arrive at this new website, because there is metadata associated with a paske. The system can intervene. And before you even start typing on the keyboard and trying to type a username, the system can pop up and say, Hey, stop. I have PSS for you here. Here is the list of PAs keys. We show you the display name, we show you the username. You simply pick the one you want to use, click on it, touch your fingerprint, and you're assigned it. So the discoverability, because we have this method that associated this PAs, is another reason why. They're just purely better than, the traditional method of using or passives. Yeah. One other

Tim:
00:28:02
detail. Cause I think it's important thinking about the history and the U two F, even some of these older protocols. The other thing that's stored with the credential is, let's call the relying party id, Which is all of these PAs keys are solely bound to single site, a pasky created for login.microsoft.com can't be used against accounts.google.com, And that's just one of the core security and privacy features of this technology. And that's existed pre pasky that existed with normal FI oh two credentials that existed with U two F, all these things, right? They're called Origin bound credentials, which is one of the most important things about them. So if I go to amazon.com, I am never gonna see a list of credentials for google.com in that list. it's, prohibited by the specs themselves,

David:
00:28:41
So you're mitigating the possibility of cascade to zero, hopefully.

Tim:
00:28:45
Yep, exactly.

Mishaal:
00:28:47
you touched upon a lot of topics there Christian, and thank you Tim, for adding that additional bit of detail. As you mentioned, when you create a PAs key, what's stored on the device is a private key, and that's unique to that device, but it can be backed up to a cloud service provider such as like Google Password Manager. is there going to be some way to transfer those pro out from say Google password manager to other password managers? If you wanna switch to last pass

Tim:
00:29:11
or something.

Christiaan:
00:29:12
I mean, I thoroughly hope so. I think that is the intent is that users should be able to, I mean, it happens, right? Today you're on Android, tomorrow, you decide you wanna buy an iPhone. We need to allow the user specific platforms. The problem is hard though, We've already said that we wanted to do better than passwords. Today with password managers, you can export your passwords to plain text. they're, they're strings anyway, right? It's fairly easy. It's not that great if an attacker were to get hold of your list of passwords, but because websites claim and act on passwords as if they're inherently insecure anyway, there is normally additional layers of authentication. There might be mfa, there might be other stuff on top of that, With PAs. We're hoping that that is your secure credential that you use and that there wouldn't be additional step up needed in the normal sense when you log in with a paske. If we therefore allowed users to very easily just export these things to a file on a disc, that would be the exact way that attackers would now try to get hold of these and essentially compromise the system. So it is a little tricky for us to figure out exactly how we architect the solution. I don't know if exporting to a file on this is the right solution, even encrypting that file with a password, I think users could be tricked or do into doing that, revealing that or uploading that file somewhere, which would counter or go against all the security guarantees that Paske are supposed to provide. So I totally agree with this sentiment and I think that's absolutely something that we want to support how we do that in practice. I think we're still a little bit unclear. I know, Tim, if you have any additional like, insights on that one.

Tim:
00:30:41
Yeah, I was just gonna say that that's probably top three things we've been thinking about since we launched this. The interesting thing, and Michelle, I know we talked about this completely casually one day. This all also ties into a lot of the identity wallet stuff, So, we can think of a paske as a, a wallet credential, just like a mobile driver's license. Just like verifiable credential. All these other alternative technologies for claims transfer, Who I am, beyond authentication, So we are also thinking about this in the context. could we come up with a universal credential transfer type format, Where it can move your pass keys, it can move your verifiable credentials, it can move maybe even your mobile driver's license. That's a very political topic, so it won't go there. But like those types of credentials between platforms and ecosystems and wallets is a password manager just now gonna become a wallet, it kind of was the original digital wallet in many ways. Sure there were just bear data in their bear credentials. But, we expect password managers to evolve into pasky managers and all these things, so we really wanna think about it holistically as well. And we certainly didn't wanna rush into a solution that dumps a text file out So, top of mind the feedback was loud and clear. we knew it was coming and we just wanna make sure we can do it the. Great.

Mishaal:
00:31:44
And one of the other things I wanted to talk about is how exactly cross device authentication works. And I, I know that's one things that's top in mind for people who are interested in paske or wondering how paske replace passwords. With passwords you have the password, with you, you can use it on any device that you have access to the internet or sign into those apps. Whereas with past keys you have the private key that's stored on the device and say, the typical example is you have an Android phone and a Windows pc and you created an account on your Android phone. Private keys on your Android phone backed up to Google Password Manager. But your Windows PC is, windows OS with Microsoft Manager. And so how exactly would you use your credential, sort on your Android phone to sign into a website that's, on your Windows pc and how exactly does that

Tim:
00:32:28
process. Absolutely. Yep. so, one of the biggest misconceptions, which I wanna start with is that the PA key itself, as Christian mentioned, the private key and the MEDA moves across devices. That is not what happens assigned assertion moves, just like if you're familiar with some of the federated login scenarios was signing with Google, Your Google account credentials are not moving to the other party. It's an assertion that's signed. So it's, a very similar concept. It's a lot more complicated, obviously. But this is another great example of something that's implemented in the c a layer, which is not something a website needs to worry about. So, The pattern we'd like to evangelize with it is that users are not using their phone to sign into something on their desktop or laptop every time we imagine as a way to bootstrap the other ecosystem, So you can imagine a world where, Android, iOS are already shipping past keys. Windows will be a little bit further behind just different dev cycles. It's a old operating system. So obviously I may have PAs keys on my phone that I don't yet, have a PAs key yet in Windows. So when the day comes, when Windows has passkey support and I wanna sign into a service on Windows, the first time I use my phone, I go through the pairing process. The linking process for the first time. And then the hope is that as a relying party, you would see that, that. Credential came in from another device, there's actually some metadata that let you see it, and you pop up something that says, Hey, do you wanna actually enroll Windows or this device so that you don't need your phone every time? And then at that point you have a, a PASKY that's syncing in the Microsoft ecosystem and in the, let's say Google ecosystem. And then you never need your phone to sign into that service on Windows again. Right? So we, hope that's the pattern. That's what a lot of the developer docs on PAs, keys dot, Dave will evangelize because we don't think it's a great experience that the user has to take their phone out every time. There's nothing stopping them from doing that if they want. But it's not an ideal experience. And so, the way it actually works, there's been a heavy, heavy focus on QR code based authentication, That's what it is. And it's really not. The only thing that QR code does is allow the devices to link. And we're explicitly saying, linking, not pairing, because it's not like a Bluetooth pair, There is though actual Bluetooth layer persistent relationship between these devices. What's happening is when you, scan the QR code you're sending part of a key to a key agreement. And also you're proving proximity, One of huge security properties of vital authentication is proximity, Usb, obviously it's plugged in physically. NFC only works on top of it, And so, using Bluetooth low energy beacons, which have a very short, it's. Bluetooth Classic, where it goes into another apartment. It's a much shorter range. We can actually prove that the phone is nearby to the client, which would be the desktop in this case which helps check the box of proximity. And what essentially happens is there's every authenticator, so let's call the phone the authenticator. They have a cloud service that actually is, think of it as a big router that can actually help the request get to the phone and back, it's to like a web socket model, And so when you scan the QR code there's some information that's shared in Bluetooth advertisements, ble the advertisements between the devices. Obviously they have to be close to each other to see that. And then both parties can actually go establish a secure connection to this service. And then at that point, the same exchange that happens to a USB security key or n. Happens just over that transport. So the official protocol level name for this is called hybrid. Not very exciting. But the way we refer to it more generically is cross device authentication. it's very, very flexible. obviously cross ecosystem. You can do this today, windows, Mac, Android, iOS and it's super, super user friendly. Users are familiar with QR codes now, and the nice thing is too, is actually on Android specifically you don't have to do the QR code step every time after you've done it once. As long as you leave the remember me checkbox on your phone side, you'll just click on your phone in the notification. So I'm curious,

David:
00:35:51
On the legacy side of this, a lot of people are going to be trying to share between say, an older desktop PC and their smartphone, which desktop, PC doesn't have a camera, it doesn't have Bluetooth. are there fallback

Christiaan:
00:36:04
methods. Yeah, that's, a good question. I think there's two things. The first thing, I'll quickly just go back to what Tim said, because I think it also feeds into this answer a little bit, is early on we spoke about PAs keys and how they get synced using Google Password Manager. I think there's one important thing we have to call out. Passwords in the Google Password Manager are synced to wherever your Google password manager was, You could even have it on iOS, you could have it on Windows, You have it on Android. PAKEs are fundamentally different because of the security properties that we wanna guarantee with PAs, and also the usability that we want with Paske. Pakis are a system provided component, which means if you have PAs on Android, They stay on Android, they'll move to your other Android devices when you sign in there. But your PAs keys on Android is not gonna become available to Chrome on Windows. The only way to use it is using this cross device mechanism that Tim was referring to. The same with iOS. You can have your Google password manager on iOS all day long. Your PAs keys are not gonna be there right now. You have to use your Android phone in order to scan a Q code on your iPhone, which will then provide this local mechanism for transferring the signature over to sign the user in. Reasons for that is mostly security. There's also another reason there, in terms of app consistency on. iOS Chrome and Safari and your apps running on iOS all use the exact same PAs out of the exact same store. So users don't have to worry that Chrome is storing Paske over here. Facebook is storing Paske over there. Safari is storing PAs keys over there. No, no, no. They're all stored to the iCloud key chain today. so consistency at the platform level was very, very important to us when we devised the system. So just one thing I wanted to call out, back to David's question, which is like, okay, now that there's even more discrepancy here, like a user goes to an old Windows device, doesn't matter if they're using Chrome, they're not gonna have their PA keys there, right? Their past keys is on their Android phone. How do they use them? the main issue here is that proximity is critical to the security of the solution. If we don't have that local proximity check that we have through Bluetooth, it technically means again, that a user can be duped. Being fished essentially, some person, somewhere in a different country could go try to get the user to go to a website, approve a login on a phone. And because there is no proximity checks, you are not sure that you're logging the device in, that you're looking at, you might be logging the attacker in that's, a thousand miles away. So to us, the proximity is very important. We have b. As our main mechanism for doing the proximity today it was a lowest common denomin It's available in lots of places. It's fairly robust. It works across, devices. We are looking into other alternatives there as well. Things that we might wanna do in the future. This one is not gonna help for David's question. UWB, for example, ultra wipa, even better, in range and stuff. But again, that's technology that'll come out in the future. Depending on how many users are in this boat, where they have older systems that they need to sign in, one might think of other types of local transports which we could use to prove proximity. There are many technologies available to us, like local network access is one that some applications use to gauge whether, users are physically co-located. That's not something in the protocol right now, but it might be something that we wanna look at in the future. Today we're. Users are gonna have to live with one leg in either ecosystem. One leg, probably still in passwords for a while on these older legacy devices. One leg with PAs keys. The benefit of this is to the relying party of the services implementing it. The less the user is subjected to passwords, the more scrutiny can we subject them to when they do need to log into that legacy system. Today we have to allow passwords through as a first class method because that's all we've got. We can actually start to demote passwords to actually, you wanna use a password, maybe you can't log in immediately, like maybe we subject your account to in one hour hold. Or while we lost verifications to all your other logging devices. There's lots of things that we could do if passwords weren't to be treated as like a first loss login primitive. But we don't have a straight answer today for legacy devices. I think passwords plus some additional scrutiny is probably what we're gonna have to do there for a while.

Tim:
00:40:03
Yeah, I think realistically in the short term, and let's say. Two to five years. the goal is to de-emphasize passwords, Start removing them solely. A user that has, let's say three pass keys may be treated differently from a sign and flow than a user who has one pass key and a password in sms The capabilities are there to have very rich, dynamic experiences that can change over time as these levels change, Of, of users with pass keys and penetration and all that. So it's really about de-emphasizing as Christian mentioned, like you come in, you've used a pass key for a year now three different pass keys from 3D devices, and all of a sudden you come in from a device with a password, Red flag should go up, And that's all authorization logic, not necessarily for an authentication decision.

Mishaal:
00:40:43
And just to be clear, existing accounts that would've been created with username, password, those can be migrated to used pass keys. Is that right?

Tim:
00:40:52
It's not automated, right? if you actually see this on PayPal, I believe they're the most widely known deployment right now. If you sign into your PayPal account with user and password, they're probably gonna do an SMS check. And then if you're on a platform they're supporting, which I believe right now is,, iOS, that's their first rollout. They will actually pop an interstitial that says, Hey, upgrade to a pasky. So the user still has to do something. The relying party has to do something. We get asked a lot, can we just bulk enroll a bunch of PAs? I think there are some things we can do to make that easier, which I think we're starting to look at. But it's unfortunately not like just this, flip a button and they go. But you know, in theory it's a one time thing for each account. So, Another

Mishaal:
00:41:29
question that I had is what will happen to the existing trove of security keys that people are using? will you still see security keys being used for authentication? Cause I know when you're. Using your phone, you can do biome authentication or a pin to say, I want to use this past key. And where will we see security keys being used in that process? I

Christiaan:
00:41:47
mean, I think a unique perspective on this because that's the question that we have to ask for Google accounts today, We have lots of users using security keys on Google accounts. We are fully marching ahead in order to implement PAs keys on Google accounts as well. And then the question becomes what happens to security keys now, I think from the get go. our thinking has always been as we're moving on, web and platform credentials and toskey that we didn't wanna leave security keys behind and treat them as second class citizens. So today, when a website, when a relying party or developer supports PAs keys, they have to go out of their way to not support physical security keys, The way that I think about this is if you have a five two compatible security key, that five two compatible security key can store PAs keys, They might only be on that single device. They're not synced to a cloud or something like you might have with your phone, But your PAs key now lives on your physical security, and you should be able to use that exactly the same way that you use your phone now on the phone, you authenticate by touching your fingerprint or typing a pin. On a 5 0 2 security key. I mean, I have some security keys with fingerprint readers on them, right? That's stuff that exists. If you don't have one of those most of the 5 0 2 security keys out there can authenticate using a PIN code. So you can set a four digit pin code. And the nice thing there is, it's not like a password, it's not sync remotely anywhere. It's just on your security key. And the same PIN code can be used for all the websites for which you have PAs keys on that security key, right? so to go to Google and register a fighter two security key, or to go to Google and register a, physical phone in the future as a paske should be exactly the same. And for users who think that they're better served by having the physical security key, Maybe it's because they're afraid they might lose their phone, they wanna have a backup. Maybe it's because it's a, specific type of high risk user who's worried about, having PAs keys on phones and they prefer having a security impact. We're essentially opening security support up to much, much, much wider array of websites through the PAs key initiatives. Because websites who used to look at this and say, securities are teenage, I'm not interested in implementing it. PAs keys are great. I wanna implement that automatically. Those websites will now get security key support almost for free, which I think is a very nice side effect of the way the protocols been architected.

Tim:
00:43:58
Yeah. And We plan at least on the window side, a phone and a security key will always have equal footing, any remote device will show up on the windows, hello screen. Security key will still be there. We're not planning on deemphasizing it at all. We have in the enterprise space, and I hate the word enterprise, but like the more work centric things we expect security key usage to actually increase. And so that will remain an option as it is today.

Mishaal:
00:44:18
We're getting close to time. So, I'd like to give you both an opportunity to do a quick outro. So where can people go to learn more about past keys as well as, follow you online?

Tim:
00:44:27
Yeah. So actually, as part of this initiative, one of the things that I think we. I shouldn't say fail because everything's a learning process, but in this particular iteration of this technology I think we, were able to come together and have developer resources available pretty quickly, Comprehensive ones, right? there's a lot of resources that happened over the years. With Web off and other things, but there's 10 different sites to go to. And they all do different levels of detail and they don't necessarily pull together a story. So that's where Pass keys.dev came from. That's a collaborative effort between multiple companies throughout Fido and w3c. That's a community effort. All the code is on GitHub. You can see pull requests. You can submit changes, We want keep it as open as possible. It's more or less governed through. A group called the W3C Community Adoption Group. If you are a developer and you have developer feedback on pakis.dev under about, there's links out to that group, you can join that free of charge. And that's where we take in feedback and relay it to the actual working groups and even the platforms and other things. So I would highly recommend you bookmark pakis.dev at a minimum. It's got a great device support matrix that we literally update every week with this new and flag is supported. So, shameless shameless brag though, something I worked on, but was super happy with it. And we've gotten a lot of great engagement on it. On Twitter. I don't know if I hate saying that anymore, but I'm Tim Capal on Twitter. I still use both. And then on Macon what is my thing? It's like a whole Tim Kali InfoSec exchange. So we could probably put that, it's actually on my Twitter. It's probably the easiest place to find it.

Christiaan:
00:45:49
And then from our side, I think, VAs a great resource here. We also have. Some documentation over on the Android side. I do realize that it's not complete yet. at this point we are working on that actively, but if you go to developers.google.com/identity/pas keys you can find our documentation and we'll be updating that. As more functionality gets pushed out there. There is a whole lot of things happening on Android with PAs over the next year. We've already publicly indicated that we want to support third party pasky providers in Android. That support will be coming next year. There is a whole new. Way for applications to access pakis things, that be, coming out early 23, towards the middle of 2023. So lots of activity and everything essentially will be published on that, developers of google.com/identity/pakes website. And then of course, on, on Twitter, I haven't figured out how to make Master on Work. I tried an instance that never sent me the email to set up my password, so not there yet. But on Twitter, you can follow me at Christian with two as brand. So if you're interested, usually if something happens on the Android or on the Google side, I tweet about that pretty, pretty quickly. So if you're interested in anything happening on Android or Google with Pakis, feel free to gimme a follow on.

David:
00:47:01
And thank you both for joining us. There isn't a great Esper plug because we don't really do anything with past keys, but this has been immensely fascinating. The evolution of the password. I mean, obviously we all know that passwords are bad. I think either for the right reasons or wrong reasons, everybody hates passwords. So I'm actually curious about one thing, and this is a bit of Android esoterica Christian maybe, you know, but Tim maybe you know as well. So when it comes to two-factor authentication, everybody's got a little bit of their spin they like to put on it. I've always found Google's to be not unique, but it's the only time I've seen it used. Google

Tim:
00:47:37
uses a two digit

David:
00:47:39
number matching system. You get three numbers to choose from. Do y'all know what the philosophy or logic behind that is as compared to a six digit confirmation code?

Christiaan:
00:47:51
that, that's a great question.. Well, I mean so much to say about that, right? So, I think in general, sick digit confirmation codes is necessary when you have a one way communication architecture, like in the old way where you authenticated using SMS otp. So one time password sent via sms, It's a one way communication channel. Google sends your phone, then from the phone you type it back into Google, but I mean, you're not replying back on the channel that you got the code from, right? So in order to prove to Google that you got the right code, six digit codes is usually the standard for that, which is also the same standard. We ended up using mostly Fort OTP codes generated by applications, So you have like an app like Google or something that generates TTP codes. Usually six digits is from an entry perspective, that was good enough so that we can say, well, if someone entered that code, chances of someone just like randomly guessing your code, probably pretty slip, So six digit is where we had it. Then we moved away from that and we moved to push based authentication systems where we sent a message to your phone. You reply on the phone directly by saying, yeah, it's me. Technically no code is needed there. When you say yes on that particular device, you can go cryptographically from that device back to Google and say, the user definitely saw this prompt on their phone. We know we sent it to the right phone. You send that message back, you can append any length code essentially that you want. There might be a cryptographic signature that the companies that, so there is no need in that particular example for showing any codes. Apple is interesting in their implementation. They would do the push, but then they would also still show a code that you have to enter. I mean, from our perspective, that's not really, super required. And in most cases, when you log into Google, the yes on your phone is all you have to do. However, in certain cases when logging into Google depending on leg schedules and other things, we might also in addition, show you these two digit numbers and have three of them that you have to pick through. The philosophy behind that is essentially saying that it's the same as this Bluetooth bearing thing, If you're on your car and your current comparative Bluetooth devices together, usually the device will show the same code and say, Hey, just be sure that you can see the same code on both. I mean, who checks it, right? Everyone just clicks past its horrible ux. But the point there is on the Google side, we wanna be sure that you are logging into the right device. You're not accidentally logging in some one other's device that also just happened to, at the same time, initiate the logging request, having your username and password. And when you say yes, you're actually approving their device and not your own. They would technically have a different code on their device, a different two digit code that we displayed on your phone. So this matching here is to weed out, an attacker that just happened to, at the same point in time, maybe they're sitting next to you in startup, they're watching you log in, and then they did enter exactly at the same point that during enter, when you approve on your phone, who knows which user device you're actually gonna approve. Now it's not foolproof, There are still ways to get beyond that. If you're a sophisticated attacker with a man in the middle, you can probably defeat some of these things as well. But at least it tries to weed out 99% of those types of timing attacks, where these codes would then allow only the right device to be logging and not the wrong device. So, a little bit of a long winded answer, but there is method in the madness here, but in most cases, users wouldn't even see those.

Tim:
00:50:58
So we, I knew there was, we had, we had something, so for our enterprise customers, right? Azure ad we had the same thing. We had number matching. we actually now make the user type in the number because the number of users that were correctly selecting a random number because it popped up, was insanely high, right? The probability is still pretty good. So we actually have the option now, admins can turn on. You actually have to type the number for us. Microsoft employees we have to type in the actual number. You can't just select it So it, funny to watch the progression of that experience. We call it number. That's,

David:
00:51:26
that's fascinating because my anecdotal experience, and I know probability makes, means this means nothing, is that I get it wrong every time I try to guess it instead of looking over at my phone every single time.

Tim:
00:51:37
Least Yeah's funny. Yeah, I, I think we actually did a blog post that has some of the numbers. I'll see if I can dig it up. Yeah, I knew

David:
00:51:44
there was a good story there and it was a good story. Thanks for sharing, Christian, because I don't think many Android users would have any idea why that system exists. So hopefully they learned something and hopefully they learned a lot today. Talking about paske. If you're not interested in personal security credentials or credentials otherwise, but securing devices specifically, come talk to us at Esper. We do Android device management better than most places. Every other place, honestly, esper.io, you can visit us and Michelle and I are both on Twitter and you can find us there. Thanks for listening everybody, and we'll see you next time.