Episode 30

What is a passkey and why should you care?

Published on: 19th December, 2022

The FIDO Alliance isn't a fan club for dogs, but a consortium of big tech companies that's trying to make authentication more secure. The Alliance has a lofty goal: To kill the password and replace it with something better. Enter the passkey.

You've probably read a blog post or two about it, but you may be wondering what the fuss is all about. We invited two of the foremost experts on the topic to join us on Android Bytes and explain how passkeys work and why we're better off without passwords.

Christiaan Brand is a Product Manager on Identity and Security at Google and Tim Cappalli is an Identity Standards Architect at Microsoft.

  • 03:09 - What's wrong with passwords?
  • 05:17 - How did we get to passkeys?
  • 07:47 - How do passkeys reinvent authentication?
  • 11:50 - What is the FIDO Alliance?
  • 14:38 - Are passkeys convenient to use?
  • 15:47 - What is WebAuthn, CTAP, and FIDO2?
  • 18:01 - What is a FIDO credential? What is the meaning of "passkey"?
  • 21:57 - At a high level, how do passkeys actually work?
  • 24:47 - What makes passkeys more resilient to phishing and data breaches?
  • 25:52 - How are passkeys backed up?
  • 27:15 - What happens if you forget that you made a passkey for a certain site?
  • 28:01 - Can you reuse passkeys?
  • 28:51 - Can passkeys be exported or transferred between password managers (passkey managers?)?
  • 31:44 - How do you use a passkey stored on your phone to login to a website on your PC (or vice versa)?
  • 35:50 - Is there a fallback method to support legacy devices? How long will passwords stick around?
  • 40:41 - Can you create a passkey for an existing account?
  • 41:28 - What will happen to physical security keys?

Learn more about passkeys at passkeys.dev and developers.google.com/identity/passkeys.

Android Bytes is hosted by Mishaal Rahman, Senior Technical Editor, and David Ruddock, Editor in Chief, of Esper.

Esper enables next-gen device management for company-owned and managed tablets, kiosks, smart phones, IoT edge devices, and more.

For more about Esper:

New from the Esper blog:

Our music is "19" by HOME and is licensed under CC BY 3.0.

Transcript
David:

Hello and welcome to Android Bites, powered by Esper.

David:

I'm your sometimes host David Ruddick.

David:

And some weeks I'm joined by my co-host Michelle Ramen, who really

David:

is the, the brains behind this show.

David:

I'm more just a talking head.

David:

This week we've got some really great folks on to talk about a

David:

topic that, honestly, I know nothing

Tim:

about

David:

PA

Tim:

Keys.

David:

I'm really interested to learn.

David:

And Michelle, would you like

Tim:

to introduce our guests?

Mishaal:

Thanks David.

Mishaal:

So on today's episode, we invited Tim Capal and Chris John Brand.

Mishaal:

And I wanted to give you guys, , both the opportunity to, , introduce yourselves.

Mishaal:

Like what company do you work for?

Mishaal:

What exactly do you do?

Mishaal:

And how much do you know about Paske?

Mishaal:

Like, why are you two the Paske guys?

Mishaal:

So why don't you go ahead, Tim

Tim:

or Christian?

Christiaan:

Yeah, go ahead.

Christiaan:

I'm happy to go first.

Christiaan:

All right.

Christiaan:

Hi folks.

Christiaan:

I'm Christian brand.

Christiaan:

I'm a product manager here at Google.

Christiaan:

I've been working on, , fighter related initiatives here at Google for.

Christiaan:

Probably a little bit over 70 years, , so far.

Christiaan:

And before I came to Google, , I had a startup and we were also part of

Christiaan:

the Fido Alliance and working there even before I formally joined Google.

Christiaan:

So I have been, , , in this space for quite some time.

Christiaan:

, our goal was always to bring this technology to the masses, which

Christiaan:

really is what PAs Keys is all about.

Christiaan:

And when I say this technology, I'm talking about the technology

Christiaan:

that, , we've together with a bunch of other companies, , Tim from Microsoft

Christiaan:

here, will tell you a lot more about their, , perspective on this as well.

Christiaan:

But, essentially there is a whole bunch of companies part of this thing called

Christiaan:

the Fido Alliance, Microsoft, the third Apple is there, Google is there a

Christiaan:

whole bunch of other companies as well.

Christiaan:

We've been working in this space for four years.

Christiaan:

But the technology was niche.

Christiaan:

It was for users who had very specific types of hardware called Fido, security

Christiaan:

keys, and other types of technologies.

Christiaan:

, and with past, we are really bringing that technology to everyone

Christiaan:

and making everyone online safer.

Tim:

Thanks, Egen.

Tim:

Yeah.

Tim:

Hi everyone.

Tim:

My name is Tim Capal.

Tim:

And I work at Microsoft as a standards architect.

Tim:

So I actually work heavily in the Fido Alliance with Christian and

Tim:

with Google as a partner as well.

Tim:

And also , a lot of this technology is also designed in the w3c, ? So

Tim:

that's where a lot of the browser components come into play.

Tim:

I joined Microsoft smack d in the middle of Covid March, 2020

Tim:

when the world was shutting down.

Tim:

And so before that, I actually worked in network identity, ? So

Tim:

wifi network wifi, roaming, wifi identity, all that fun stuff.

Tim:

And I've had a passion for wanting to kill passwords since

Tim:

I kind of started that journey.

Tim:

So, , made some progress on the network side, right?

Tim:

There's still, some things that need to be done there, but was super excited

Tim:

to start working on this problem at Microsoft as well, albeit at a different

Tim:

layer, , , on the web for apps.

Tim:

But similar problems exist, passwords are , one of the top problems with.

Tim:

All, all, all cyber security issues these days.

Tim:

So, super, super excited to collaborate with Google and Apple and the vital

Tim:

alliance , on this whole pasky thing.

David:

Yeah, my passion for killing passwords, I have never

David:

seen it put so eloquently.

David:

I

Tim:

love it.

Tim:

So, yeah, I had a nickname.

Tim:

The customers at my last job gave me the nickname TLS Tim, because the

Tim:

solution on the network side for not using passwords is TLS certificates.

Tim:

And I got a little worked up when I was talking about it as usual,

Tim:

like, let's kill the passwords.

Tim:

And so now my new nickname, I was coined on Twitter as Tim Kaki.

Tim:

So , there's always some nickname somewhere.

Tim:

Nice.

Mishaal:

So I think we all have a general good understanding of why

Mishaal:

we want to kill passwords, , among us , but some people may not be as on

Mishaal:

board or it might be as familiar with why you want to go ahead and do this.

Mishaal:

So you want to convince people to switch away from the password,

Mishaal:

you need to convince them that whatever you're building, the

Mishaal:

alternative is better in every way.

Mishaal:

It has to be not only safer, it has to be as convenient, if not

Mishaal:

more convenient, and it also has to be, easy to understand and use.

Mishaal:

Why don't you just start off by telling us what exactly is wrong with passwords,

Mishaal:

what makes them inherently more insecure than whatever you're working towards right

Christiaan:

now?

Christiaan:

, I'll jump in.

Christiaan:

I mean, so, so many things wrong with passwords, right?

Christiaan:

There are shared secrets for one, ? You know, Your password, the site on the other

Christiaan:

side also essentially knows your password.

Christiaan:

Yeah.

Christiaan:

Maybe they have a hash, whatever, right?

Christiaan:

But these hashes are not always that hard to reverse, and there is a whole bunch

Christiaan:

of reasons why passwords , as a shared secret model , has limits , on what you

Christiaan:

can achieve from a security perspective,

Christiaan:

if that other end of your password gets breached, ? Let's say I use

Christiaan:

a password ABC one q3, right?

Christiaan:

And I use it on website X.

Christiaan:

If website X gets breached, now everyone knows my password.

Christiaan:

If I then went and I reused ABC 1 23 across various websites, Let's be

Christiaan:

honest, most users do, or at least until password managers became a thing,

Christiaan:

that was what everyone did, right?

Christiaan:

So now it means that when your password on website X is breached,

Christiaan:

your password is breached everywhere, ? Because it's essentially the same

Christiaan:

password that you keep reusing with the same username, password combo.

Christiaan:

So, remote end breaches, big problem with passwords password

Christiaan:

reuse, giant issue there.

Christiaan:

And then of course, , my favorite thing to hate about passwords.

Christiaan:

They're super easy to fish.

Christiaan:

And I think that has really been , what at Google we've been

Christiaan:

interested in solving ever since we started on this journey, right?

Christiaan:

Our journey of the Fighting Alliance didn't start because

Christiaan:

we wanted to kill the password.

Christiaan:

It started because we wanted to kill fishing.

Christiaan:

Back in 2009.

Christiaan:

A bunch of, tech companies, Google being one of them was subject to

Christiaan:

the Operation Aurora Hacks, which, By this point, it's pretty public.

Christiaan:

, and how all that started again is kind of like with Phish, right?

Christiaan:

Because usually these attacks start with Phish.

Christiaan:

We wanted to solve that problem.

Christiaan:

We still, we want to solve that problem.

Christiaan:

, the technical solution to this was essentially what

Christiaan:

became the PHY two F standard.

Christiaan:

We first implemented it internally for our own workforce and then we

Christiaan:

wanted to implement it for our users.

Christiaan:

And then at some point we decided, well, if we now have five B, two F and we've

Christiaan:

essentially solved phishing, what are we even doing with passwords any longer?

Christiaan:

Can't we just get rid of them too?

Christiaan:

And I think that is then.

Christiaan:

Microsoft joined the FI alliance, I think it was back in 2015.

Christiaan:

Tim can tell the story from there on out, but really at that point it was

Christiaan:

like, why are we even doing passwords?

Christiaan:

Can we just stop doing passwords and simply rely on the technology

Christiaan:

that we now have in FI Alliance?

Christiaan:

, which essentially gets us now from , like I said earlier on, a niche solution

Christiaan:

into the mainstream consumer solution.

Christiaan:

Because for mainstream consumer solution, you can't talk about, oh, this is a lot

Christiaan:

more secure and oh, this sells fishing.

Christiaan:

You need to talk about convenience.

Christiaan:

This needs to be simpler, it needs to be easier to use.

Christiaan:

It needs to be faster.

Christiaan:

And that is, I think, what we finally have with the current set of standards,

Christiaan:

which essentially collectively , we call Paki uh, over to 10 because I'm

Christiaan:

short term, have a lot more to, to talk.

Tim:

No, I, I think one of the big changes that happened since, Christian

Tim:

talked about rolling U two F out to Google

Tim:

is that , pretty much every device that CHIPS now has biometrics, ? , and a secure

Tim:

element and all these pieces that , , you couldn't weave a story together for

Tim:

both a user experience standpoint and from a security standpoint across the

Tim:

board, ? There was all this fragmentation.

Tim:

So we're now at the point where even low end devices have pretty high security

Tim:

capabilities compared to , even five years ago, ? So , the fact that if someone

Tim:

with a $2,000 phone and a $500 phone can all securely log in online using either

Tim:

biometrics or device pin is game changing,

Tim:

? right?, that is why the time is now

Tim:

? On the enterprise side, Security keys with a thing, right??

Tim:

The little, USB or NFC dongle.

Tim:

And that has cost and users lose them and users don't understand them and there's

Tim:

no good name for them, ? All these things that compound to the point where it's

Tim:

just another annoying thing that it gives you that you have to carry and use.

Tim:

. And the most ironic part about the security key thing nowadays

Tim:

is like everything else that's on my key chain is, either on my

Tim:

phone now or moving to my phone.

Tim:

The only thing I have left on my key chain, I have a security key, but

Tim:

I'm a nerd, so let's wipe that out.

Tim:

But , my mailbox key, that's the only thing that's like

Tim:

analog and on a key chain.

Tim:

So telling users to secure their digital life, you have to carry

Tim:

this thing on your key chain.

Tim:

that's a hard sell, especially from all these same companies that are

Tim:

working to give them digital access to the same credentials on their phone.

Tim:

I love your

David:

philosophy about de keying your entire life.

David:

I'm all about it.

, Mishaal:

there's varying, varying degrees of how closely people follow best

, Mishaal:

practices , or what people say is best practices for securing your online life.

, Mishaal:

? Do you use multifactor authentication?

, Mishaal:

Like what kind of multifactor authentication do you use?

, Mishaal:

SMS based, app based, security key, et cetera.

, Mishaal:

And biometric authentication, all of these seem like they're just larger and larger.

, Mishaal:

Band-aids being applied on top of the foundation that was,

, Mishaal:

inherently insecure, password based authentication as a primary.

, Mishaal:

And now , pasky seems like you're ripping all those band-aids off

, Mishaal:

and saying, okay, let's restructure everything from the beginning.

, Mishaal:

, let's rethink completely how we think about primary authentication and start

, Mishaal:

from a more secure model from the ground.

Tim:

Is that like,

Christiaan:

I think that that's the whole point, right?

Christiaan:

At some point, like I think up until maybe, I don't know, 2005, 2006,

Christiaan:

whatever, like passwords were okay, right?

Christiaan:

We all had the same password in which we typed in and things were okay.

Christiaan:

Then we started introducing password complexity requirements.

Christiaan:

Then we started introducing password rotations.

Christiaan:

Then we started to implement multifactor on top of this, ? It

Christiaan:

really became unbearable, right?

Christiaan:

To sign into something new.

Christiaan:

Every time I have to create a new account, which nowadays you have

Christiaan:

to do for everything online, even.

Christiaan:

Technically shouldn't even need an account you end up creating an account every

Christiaan:

time I have to pick in your password.

Christiaan:

And it, really is just so frustrating, not because of how password used to

Christiaan:

be, but what passwords have become.

Christiaan:

. is, , it is so cumbersome to deal with them.

Christiaan:

, and has happened with the bandaid?

Christiaan:

It made the usability of passwords worse and worse and worse and worse to a point

Christiaan:

where, , most of these, I I look at some family members here , who deal with

Christiaan:

online account, their strategy is to bang some numbers on the keyboard whenever

Christiaan:

they need to create a new account.

Christiaan:

And then when they need to resign in, they go through the password

Christiaan:

reset email link because , that's the only way that makes sense to them.

Christiaan:

And I think , if that's where we are that's really a broken place.

Christiaan:

So,, we really need to reinvent that.

Christiaan:

And yes, you're absolutely right.

Christiaan:

Paske is a, from the ground of, rearchitecting of how authentication

Christiaan:

on the web is supposed to.

Tim:

Right.

Tim:

the Goal is that we hope this is the new default credential for

Tim:

the web, ? This is the minimum bar.

Tim:

Now, if you want to do other things, because for whatever reason as a, if you

Tim:

wanna use a security GI user, go for it.

Tim:

But we need a base level credential that my mother can use.

Tim:

Everyone I know can use that has reliable and consistent across platforms , and

Tim:

works across platforms, That's one of the biggest core things we did with this is

Tim:

that this works across platforms, right?

Tim:

? It can't be, this only works with Apple and only with Google and only with

Tim:

Microsoft because one of the challenges that we had, like those middle ground was

Tim:

okay, we had passwords that were great, and then we actually started to see more

Tim:

and more of these devices with biometric centers and tpms and secure elements,

Tim:

all these great security features.

Tim:

When the user got a new device, they had to default back to a password, ? So

Tim:

we, had actually all the pieces, we had everything out there, but we needed

Tim:

to pull it together into a story that was more password like, while having

Tim:

all of the best security properties of this newer phyto technology, right?

Tim:

So that's really , what PAs keys gets us.

Tim:

If we think about passwords being a one and, , this state for the past few

Tim:

years where all these devices have the capability as 50, we're getting to a

Tim:

hundred now where you can actually truly no longer have a password on an account,

Tim:

? You don't need the password to set up

Tim:

past keys are available all the time with you across your devices and et

Tim:

cetera, ? , that was the missing piece.

Tim:

, and that's what PAs keys bring to us,

Mishaal:

right?

Mishaal:

And part of.

Mishaal:

challenge now from migrating from passwords to past keys is that

Mishaal:

everyone knows what passwords are.

Mishaal:

They understand how they work cause they've been around for so long.

Mishaal:

. I've had trouble getting my dad to use a password manager to try something

Mishaal:

new because, , it's something new.

Mishaal:

They don't really like using it.

Mishaal:

A lot of them have sticky notes still, with their passwords are a little notepad.

Mishaal:

So, paske are entirely new concept and , there's not really much, until

Mishaal:

that announcement that happened back in May from , the Fido Alliance, I

Mishaal:

didn't really know what it was.

Mishaal:

I hadn't even heard of it until then.

Mishaal:

And I'm,, guessing a lot of people, even in the tech industry had no idea

Mishaal:

this was actually going on because a lot of the work was being done

Mishaal:

through , these standards bodies and behind the scenes with all these

Mishaal:

, technical meetings that like you both were probably extensively part of.

Mishaal:

So, I wanted to get everyone on the same page and go through some definition.

Mishaal:

So, we really understand.

Mishaal:

What the heck PAs actually are.

Mishaal:

You brought this up before Christian, but can you explain what is the Phyto

Christiaan:

Alliance?

Christiaan:

Right.

Christiaan:

Happy to do that.

Christiaan:

Yeah.

Christiaan:

So, the Phyto Alliance is essentially a consortium.

Christiaan:

It is a group of companies who came together with a goal in mind.

Christiaan:

And the goal that we had in mind was simplify and strengthen authentication.

Christiaan:

. That was ultimately the goal.

Christiaan:

Originally it started primarily like I said, because of certain.

Christiaan:

Issues that was prevalent even in multifactor authentication, Even if you

Christiaan:

have an account that's secured with a user MF password and, I don't know, push

Christiaan:

based MFA or SMS based MFA or even the, ad based MFA where you have a little

Christiaan:

code in Google Authenticator or Microsoft Authenticator that gets generated

Christiaan:

technically those types of authentication mechanisms are still feasible.

Christiaan:

If you have a bad guy sitting in the middle somewhere and they can trick you

Christiaan:

into typing your password into their.

Christiaan:

They can probably trick you into typing your OTP coding there as well.

Christiaan:

And we've seen these types of attacks in the wild.

Christiaan:

So multifactor authentication as it stands today is no match for a

Christiaan:

SP fisher for someone who's really after your particular account.

Christiaan:

And actually it's become easier and easier to conduct these attacks at scale.

Christiaan:

There is tools out there and X , is one particular I think

Christiaan:

great example or bad example.

Christiaan:

I dunno.

Christiaan:

It depends on which way you go of a reverse proxy that is set up to steal

Christiaan:

credentials, ? Very, very easily.

Christiaan:

You can do it at scale.

Christiaan:

And pretty much deployed MFA technologies are susceptible.

Christiaan:

Fighter Alliance was set up to develop the next generation of MFA

Christiaan:

that would not be susceptible to these types of phishing attacks.

Christiaan:

Started with a second factor.

Christiaan:

It started with a physical thing called the security key.

Christiaan:

Then that became, well, why don't we try and build these things into phones?

Christiaan:

And then the last step was, well, if we actually want adoption here

Christiaan:

we're gonna have to make this easy.

Christiaan:

And the companies that joined up in the FI alliance, I mean,

Christiaan:

this didn't happen overnight.

Christiaan:

There was a bunch of companies in there.

Christiaan:

Google joined about a, I think about a here or a couple of months after Fi

Christiaan:

Alliance inception, . Microsoft joined later on, and then again, a couple of

Christiaan:

years later, we and Apple also joined.

Christiaan:

We have many, many other member companies.

Christiaan:

That's more what we call in, Fido language relying

Christiaan:

parties, those who be your meta,

Christiaan:

. It would be your sales force

Christiaan:

companies who would use the te.

Christiaan:

You also, of course, for anything like this , to really succeed,

Christiaan:

you need the platform providers.

Christiaan:

The folks who provide the computing platforms, which user users, and

Christiaan:

roughly those are Microsoft Windows, Android Operating System, iOS, Mac Os,

Christiaan:

? Those are the places where users are.

Christiaan:

Of course, there are other as well, ? But these are the main operating

Christiaan:

systems that users find themselves on.

Christiaan:

You want this technology baked into the platforms directly.

Christiaan:

You don't want to have to have users go download things and

Christiaan:

figure out how to set stuff up.

Christiaan:

This just needs to be secure by default, ? It needs to be built into the platform.

Christiaan:

It needs to be there.

Christiaan:

And one point that you made earlier is how do we even explain this to users?

Christiaan:

That's the cool thing about the way that this is architected.

Christiaan:

You don't really have to.

Christiaan:

. The goal with Fido and with Paki are when the user uses their application in the

Christiaan:

way that they use it today you can surface the user a prompt and say, Hey, you

Christiaan:

used to be signing in, using passwords.

Christiaan:

Do you just wanna use your face next time or your.

Christiaan:

That's all you really have to ask the user.

Christiaan:

Now, the cool thing is, ever since the advent of the iPhone 5S

Christiaan:

users have become accustomed to using biometrics to log into apps.

Christiaan:

I mean, if you have a banking app on your iPhone today, chances are when you

Christiaan:

open that app up, you're gonna supply your face or touch your fingerprint,

Christiaan:

? , ? That is where we start with PAs keys.

Christiaan:

We then do a whole bunch of things a little bit better than the, status quo.

Christiaan:

Because when you get a new device, passkey continue to work.

Christiaan:

You don't have to fall back through passwords.

Christiaan:

When you wanna sign in on another device that doesn't have a passkey on it, you

Christiaan:

can use , your phone that has your passkey in some wireless capacity in order to

Christiaan:

allow that device to sign in as well.

Christiaan:

So lots of additional flows gets enabled, but users don't need to know how PAs work

Christiaan:

and necessarily what they are to use them.

Christiaan:

We try to meet users where they are.

Christiaan:

We try to meet them at the point where, I just signed into

Christiaan:

my app using my fingerprints.

Christiaan:

That is exactly what PSS are and more.

Christiaan:

Right.

, Mishaal:

I do understand the goal and that's part of what

, Mishaal:

makes it as convenient, if not more convenient than passwords.

, Mishaal:

The fact that users don't really have to know the underlying technology at all.

, Mishaal:

But I do still think it's interesting to talk about, what has to be implemented

, Mishaal:

by, website developers and platform developers such as, Google, Microsoft.

, Mishaal:

So, some of the other terms that have come up, when you search or when

, Mishaal:

you read up on PA keys are the web authentication api or in the client to

, Mishaal:

authenticator protocol, the 5 0 2 project.

, Mishaal:

, can you explain what each of these are, , who has to implement

, Mishaal:

them or utilize them and so on?

Tim:

Yeah, absolutely.

Tim:

And the reason that there's actually two different things, ? Wen and Ctap,

Tim:

you, , you expanded already is actually to divide the labor a little bit, The

Tim:

nice thing is a lot of the complexity in these protocols is actually handled

Tim:

by , the platform or the client,

Tim:

? So that's browsers and, operating

Tim:

system is typically what interacts with other devices like a security

Tim:

key or even your phone in the case of interacting with a desktop operating

Tim:

system, ? That's something as eBay, as PayPal, as any of these , web

Tim:

properties or, app based solutions.

Tim:

You don't have to worry about all that complexity, ? The only thing

Tim:

you actually have to worry about is.

Tim:

A JavaScript api, which is called Web A, which is short for web authentication.

Tim:

And that's, really the primary entry point for , a

Tim:

website to request a signature.

Tim:

Which is ultimately what the goal is,

Tim:

? Is to get a signature back from , a

Tim:

device or on the other device.

Tim:

And the nice thing is like an eBay or a PayPal as the website don't

Tim:

necessarily need to worry about where it is, ? It could be on a security

Tim:

key, it could be on a remote phone, it could be on the local device , all of

Tim:

that plumbing and even routing is all handled by the underlying platform,

Tim:

? So ctap is an incredibly

Tim:

I'm not gonna sugarcoat that, but only a few, companies really

Tim:

need to actually implement it, which is great, ? , it removes so

Tim:

much of the developer complexity.

Tim:

, for services.

Tim:

, . The only difference really between a website and an app is generally

Tim:

what happens is , the operating systems where the apps run,

Tim:

? The app platforms try to mirror the

Tim:

? So it, is a little bit different if you're a web developer versus

Tim:

a Android app developer, There's different functions you have to call.

Tim:

Obviously one is native code.

Tim:

But , what you'll find if you look at some of the developer documentation

Tim:

is that most of them mirror the web API as closely as possible and

Tim:

translate it into the native context,

Tim:

? , if you're familiar with the web API

Tim:

language on Android, it's a , pretty quick, pick up for a develop.

. Mishaal:

And then onto the, topic of the day itself, pass keys.

. Mishaal:

So from what I understand, pass keys is the marketing name for Fido credentials.

. Mishaal:

Can we actually talk about what exactly is a Fido credential?

. Mishaal:

How is it created and stored using, say Android or Windows

. Mishaal:

as an example?

. Mishaal:

Yeah.

. Mishaal:

Do you want, can we, should we talk about the term real quick?

. Mishaal:

Just the people?

. Mishaal:

Yeah.

. Mishaal:

Talk about the term.

. Mishaal:

Yeah.

. Mishaal:

So, the interesting thing about PAs keys obviously it's a play on

. Mishaal:

We needed something that we think over time users will pick up, ? , Like,

. Mishaal:

, what the hell does Bluetooth mean?

. Mishaal:

? Bluetooth didn't actually mean anything, but people heard it

. Mishaal:

and used it and it caught on.

. Mishaal:

We think passkey actually, if a user has no context over time and they constantly

. Mishaal:

see like, oh, I'm unlocking with my face, I'm unlocking with my fingerprint.

. Mishaal:

, and I saw this term passkey, we truly believe that that will stick and that

. Mishaal:

will just become the common term to the point where we also, phyto Alliance

. Mishaal:

introduced an icon you've probably seen as a little person with a key

. Mishaal:

that we hope that eventually, let's say five years from now, users see that

. Mishaal:

and they know exactly what to expect,

. Mishaal:

? And really the goal is that when you see

. Mishaal:

you tap it, the user expects to get some kind of biometric, prompt, or selection

. Mishaal:

screen, ? ?, that is really the goal.

. Mishaal:

And that's all , we can really ask for from relying party developers ? We want

. Mishaal:

you to have either this autofill UI thing, which we can talk about later,

. Mishaal:

or a button that's assigning with the pasky, with the icon, +, and away you go,

. Mishaal:

? No more worrying about

. Mishaal:

Hello?

. Mishaal:

Should I put touch, id, should I put face Id the goal is

. Mishaal:

to have a very neutral term.

. Mishaal:

, I've actually since day one been thinking about this in the same

. Mishaal:

way that, a payment terminal.

. Mishaal:

Most users nowadays tend to recognize the tap to pay icon,

. Mishaal:

? They kind of like, okay, I can tap my car

. Mishaal:

Apple Pay or Google Pay or Samsung Pay.

. Mishaal:

Most users recognize, including my mother, which my mom is a

. Mishaal:

great test for all this stuff.

. Mishaal:

So, that was kind of the thinking with the icon.

. Mishaal:

Can we get to something similar on the web where users just see this and they

. Mishaal:

know they can get in, in a certain way?

. Mishaal:

And . Obviously we're very early days here . The term is definitely caught on almost

. Mishaal:

faster than we would like in some cases.

. Mishaal:

And the icon we're starting to see relying parties use it.

. Mishaal:

You'll start to see it across the platforms.

. Mishaal:

know, You'll certainly see it in Windows at some point.

. Mishaal:

And , variations of it being used in apple , and Google platforms.

. Mishaal:

So, that was kind of the thinking.

. Mishaal:

Now that's kind of the end user story, I think, where things tend to get

. Mishaal:

complicated, ? Twitter is a big, in many cases, a vacuum of tech people, ? With

. Mishaal:

which sometimes we're, having our own , our own debates with ourselves.

. Mishaal:

When you start getting into, , technical folks, ? We can describe past key or

. Mishaal:

past keys as two buckets, One is just the credential type, ? It's this name

. Mishaal:

of this thing that you use to sign in.

. Mishaal:

And , that's how we generically refer to it.

. Mishaal:

We say pass keys or a pass key, ? We're trying not to say passkey by itself,

. Mishaal:

cuz , it's is not a protocol by itself.

. Mishaal:

, it's just another name for.

. Mishaal:

The credential.

. Mishaal:

But then , when we talk about all these new things that Christian touched

. Mishaal:

on, these other experiences we brought along to make PAs keys easier to

. Mishaal:

use, like the AutoFi ui there's a bunch of things we've done including

. Mishaal:

the cross device authentication.

. Mishaal:

We've kind of casually also referred to that as PAs keys, ? As an experience.

. Mishaal:

. , and so maybe it's our own fault for of using it so casually, but , we've

. Mishaal:

generally been trying now to say like, oh, you support the full pasky

. Mishaal:

experience and that means the user does not have to have a password at all.

. Mishaal:

You allow them to solely sign up and sign in with , a pass key.

. Mishaal:

You're supporting the auto fill ui.

. Mishaal:

Which is a, very easy to implement, which causes the little thing to

. Mishaal:

auto pop up in username field and that , you're not restricting cross

. Mishaal:

device or those other things,

. Mishaal:

? , , and ideally we would love you to

. Mishaal:

those the three things that make up what we call the past key experience

. Mishaal:

which again, we just freely used there.

. Mishaal:

There was never really a good name.

. Mishaal:

There was never a good way to split those up, into what makes this whole

. Mishaal:

picture versus the credential name.

. Mishaal:

So we ended up in this little area, but I think now , we're

. Mishaal:

able to kind of differentiate when we're, talking about it.

. Mishaal:

Yeah, I did notice that while I was going through the documentation , it's

. Mishaal:

used interchangeably, whereas , in one sense you're talking about , the

. Mishaal:

private key, public key combo as a pass key and then also the whole process,

. Mishaal:

, the cross device authentication.

. Mishaal:

And , the multi device Fido credential experience, all of that

. Mishaal:

is encompassing the past key, ? And so it was a little confusing at first,

. Mishaal:

but I think , there's some excellent documentation that really helps,

. Mishaal:

, disambiguate what's going on here?

. Mishaal:

So I kinda have to talk about now about the experience of

. Mishaal:

creating and storing a passkey.

. Mishaal:

So, as I just mentioned, , when you generate a passkey on a device, say you

. Mishaal:

have an Android phone, you go to a website on Chrome that supports pass keys and

. Mishaal:

you generate a passkey, what exactly is being created, , what's stored on your

. Mishaal:

device and what potentially could be synced to say Google Password Manager?

Christiaan:

Great.

Christiaan:

, how did you take that one?

Christiaan:

So essentially a pasky consists of a record which has some

Christiaan:

metadata associated with it.

Christiaan:

, and that's really important and we'll talk about that in, just a second, but,

Christiaan:

Historic password in a password manager essentially is all based on heuristics,

Christiaan:

? There is a password there.

Christiaan:

There is usually a username associated with that password because

Christiaan:

that's just how we use passwords.

Christiaan:

It's this combo of username, password.

Christiaan:

And that's what password managers know s are a little bit different.

Christiaan:

When a website wants to create a pasky for a particular account on that website it

Christiaan:

sends a bunch of metadata to the system in order to create this pasky first.

Christiaan:

It sends some kind of like a we call it the, old style of user name, right?

Christiaan:

And this is mainly there because for a while there websites are probably gonna

Christiaan:

need you support users coming in with both user and password combinations

Christiaan:

and PAs, you might be logging in from a, I don't know, Samsung television,

Christiaan:

which doesn't support pasky yet, or whatever the case might be.

Christiaan:

So for a given account users will probably have to live in this world

Christiaan:

where passwords and PAs coexist.

Christiaan:

So, The first thing that the website needs to tell , the system or the app

Christiaan:

needs to tell the system to create a PAs is what's the account name that's

Christiaan:

associated with this particular pasky.

Christiaan:

And that could usually be what we call the username.

Christiaan:

So usually an email address doesn't have to be, but that's kind of like

Christiaan:

the first thing you're pausing.

Christiaan:

Then there is also a friendly display name that now exists,

Christiaan:

which you can pass in.

Christiaan:

For example, my Google account, I have a Google email address.

Christiaan:

I have a display name associated with that account.

Christiaan:

When I tried to sign into Google Google tells me, hello Christian

Christiaan:

brand with a space in between with a nice capital C and a capital B.

Christiaan:

And then my email address is shown.

Christiaan:

Underneath, almost like, it's kinda subservient to this main display name.

Christiaan:

That's all information that you can pass in when you create a pass key.

Christiaan:

There is other types of information that you can also pass in as a

Christiaan:

developer kind of like a handle to this particular credential.

Christiaan:

If, you need a way to associate that, this will not be displayed to the user.

Christiaan:

The display name and the username are things that the user will see.

Christiaan:

And then the spec, there's also the provision for a icon or a picture.

Christiaan:

, if I wanna sign to my Google account and I have multiple

Christiaan:

accounts, Google will show me.

Christiaan:

Display name, username, and a little profile picture for each

Christiaan:

of my accounts that I have.

Christiaan:

We wanted to mimic that over in Pasky Land.

Christiaan:

So Pasky technically have the ability to show the user a display name, a

Christiaan:

username, and a nice little icon.

Christiaan:

The I Icon isn't yet implemented.

Christiaan:

It, used to be in the spec.

Christiaan:

Something's changed, but that's something that we're thinking about in the future.

Christiaan:

But for now, if you're a developer, you want to passing display name,

Christiaan:

you want to passing the username.

Christiaan:

And essentially then once you pass that in, you get.

Christiaan:

A public key, ? That is the thing that you now keep on your side.

Christiaan:

And remember, early on in the podcast, , we spoke about how passwords are bad

Christiaan:

because they're symmetric secrets.

Christiaan:

PAs keys are great because they're not symmetric secrets.

Christiaan:

They're asymmetric in nature, which means the public key, which you as the

Christiaan:

website now keep that you can use to mathematically prove that the user had

Christiaan:

the corresponding private key, which is essentially what the PAs key is.

Christiaan:

The PAs key is a private cryptographic key that's stored on your device, which

Christiaan:

is generated during passkey creation.

Christiaan:

You now have that private key.

Christiaan:

Public key is what the website keeps in order to validate in

Christiaan:

the future that the user still has access to their private key.

Christiaan:

But the private key never actually gets sent to the website.

Christiaan:

The website only knows the public key.

Christiaan:

If something bad were to happen at that website and all the public keys were to

Christiaan:

leak out, nothing bad happens, right?

Christiaan:

Public keys get leaked out.

Christiaan:

They're public, they're called public keys for a reason.

Christiaan:

, there's nothing that someone can do with those public keys directly because the

Christiaan:

private key is what you would use to , essentially, confirm that you have the

Christiaan:

private key , in place, ? That you have access to this particular credential.

Christiaan:

So power key is display line, user name, private key, which is on the

Christiaan:

device, and then the public key, which you send to the service.

Christiaan:

And then what happens?

Christiaan:

With PAs, unlike with old style fighter credentials, these PAs keys that

Christiaan:

you now have on your phone, they're so valuable that we decided that we

Christiaan:

just have to back them up for you.

Christiaan:

? We don't want to leave them just on your one device, because inevitably you're

Christiaan:

gonna buy a new phone, or your phone is gonna break, or you're gonna lose it,

Christiaan:

and you're gonna have to, grab a new one.

Christiaan:

And what happens to all your pakis, ? In the old school way

Christiaan:

of thinking about biometrics, the answer was, well, it's easy.

Christiaan:

We just have the user fall back to their user M and their password, their m.

Christiaan:

We don't want that for Paske.

Christiaan:

We want the user who up Stepss into the world of PAKEs to stay there,

Christiaan:

never inheriting to fall back to passwords unless they're on a

Christiaan:

device and don't support PAs keys.

Christiaan:

But I mean, that problem will hopefully go away over time.

Christiaan:

So the thinking is like we take your pasky, we then back it up to

Christiaan:

whatever password manager you use.

Christiaan:

In the case of Google's, the Google password manager.

Christiaan:

PAs keys are end-to-end encrypted.

Christiaan:

So although they're backed up to the Google Cloud, Google actually

Christiaan:

never learns your PAs key.

Christiaan:

We can't decrypt it.

Christiaan:

The only thing we do is we store this encrypted blog for you.

Christiaan:

And if you show up on a new device and you can prove to us that it's still

Christiaan:

you by signing into your Google account and perhaps performing an additional

Christiaan:

ceremony for PAs keys in particular, you have to both have access to the

Christiaan:

Google account and you have to know the lock screen, how you unlock your

Christiaan:

previous phone that you had the pasky on.

Christiaan:

If you can do all of that, we'll decry the pasky locally for you on

Christiaan:

your Android device and then you can continue where you left off.

Christiaan:

So yes, these things , are encrypted.

Christiaan:

There is metadata associated , and I'll say the last thing on this.

Christiaan:

The reason why there is metadata associated with it is when you go to a

Christiaan:

website and you wanna sign in there and you don't know whether you have a paske,

Christiaan:

you can't remember, like who knows what they used last time that they signed

Christiaan:

into a particular website, When you arrive at this new website, because there

Christiaan:

is metadata associated with a paske.

Christiaan:

The system can intervene.

Christiaan:

And before you even start typing on the keyboard and , trying to type a username,

Christiaan:

the system can pop up and say, Hey, stop.

Christiaan:

I have PSS for you here.

Christiaan:

Here is the list of PAs keys.

Christiaan:

We show you the display name, we show you the username.

Christiaan:

You simply pick the one you want to use, click on it, touch your

Christiaan:

fingerprint, and you're assigned it.

Christiaan:

So the discoverability, because we have this method that associated

Christiaan:

this PAs, is another reason why.

Christiaan:

They're just purely , better than, , the traditional method , of using or passives.

Christiaan:

Yeah.

Christiaan:

One other

Tim:

detail.

Tim:

Cause I think it's important thinking about , the history and , the U two

Tim:

F, even some of these older protocols.

Tim:

The other thing that's stored with the credential is, let's call the relying

Tim:

party id, ? Which is all of these PAs keys are solely bound to single site, ? , a

Tim:

pasky created for login.microsoft.com can't be used against accounts.google.com,

Tim:

? And that's just one of the core security and privacy features , of this technology.

Tim:

And that's existed pre pasky that existed with normal FI oh two

Tim:

credentials that existed with U two F, all these things, right?

Tim:

They're called Origin bound credentials, which is one of the

Tim:

most important things about them.

Tim:

So , , if I go to amazon.com, I am never gonna see a list of credentials

Tim:

for google.com in that list.

Tim:

it's, prohibited by the specs themselves,

. David:

So you're mitigating the possibility of cascade to zero, hopefully.

Tim:

Yep, exactly.

Mishaal:

you touched upon a lot of topics there Christian, and thank you Tim, for

Mishaal:

adding that additional bit of detail.

Mishaal:

As you mentioned, , when you create a PAs key, what's stored on the device

Mishaal:

is a private key, and that's unique to that device, but it can be backed

Mishaal:

up to a cloud service provider such as like Google Password Manager.

Mishaal:

, is there going to be some way to transfer those pro out from say Google password

Mishaal:

manager to other password managers?

Mishaal:

If you wanna switch to last pass

Tim:

or something.

Christiaan:

I mean, I thoroughly hope so.

Christiaan:

, I think that is the intent is that users should be able to,

Christiaan:

I mean, it happens, right?

Christiaan:

Today you're on Android, tomorrow, you decide you wanna buy an iPhone.

Christiaan:

We need to allow the user specific platforms.

Christiaan:

The problem is hard though, ? We've already said that we wanted

Christiaan:

to do better than passwords.

Christiaan:

Today with password managers, you can export your passwords to plain text.

Christiaan:

they're, , they're strings anyway, right?

Christiaan:

It's fairly easy.

Christiaan:

It's not that great if an attacker were to get hold of your list of passwords,

Christiaan:

but because websites claim , and act on passwords as if they're inherently

Christiaan:

insecure anyway, there is normally additional layers of authentication.

Christiaan:

There might be mfa, there might be other stuff on top of that,

Christiaan:

? With PAs.

Christiaan:

We're hoping that that is your secure credential that you use and

Christiaan:

that there wouldn't be additional step up needed in the normal sense

Christiaan:

when you log in with a paske.

Christiaan:

If we therefore allowed users to very easily just export these things

Christiaan:

to a file on a disc, that would be the exact way that attackers would

Christiaan:

now try to , get hold of these and essentially compromise the system.

Christiaan:

So it is a little tricky for us to figure out exactly how we architect the solution.

Christiaan:

, I don't know if exporting to a file on this is the right solution, even

Christiaan:

encrypting that file with a password, . I think users could be tricked or do into

Christiaan:

doing that, revealing that or uploading that file somewhere, which would counter

Christiaan:

or go against all the security guarantees that Paske are supposed to provide.

Christiaan:

So I totally agree with this sentiment and I think that's

Christiaan:

absolutely something that we want to support how we do that in practice.

Christiaan:

I think we're still a little bit unclear.

Christiaan:

I know, Tim, if you have any additional like, insights on that one.

Tim:

Yeah, I was just gonna say that that's probably top three

Tim:

things we've been thinking about

Tim:

. , since we launched this.

Tim:

The interesting thing, , and Michelle, I know we talked about

Tim:

this completely casually one day.

Tim:

This all also ties into a lot of the identity wallet stuff, ? So, we can think

Tim:

of a paske as a, a wallet credential, just like a mobile driver's license.

Tim:

Just like verifiable credential.

Tim:

All these other alternative technologies , for claims transfer, ? Who I am, beyond

Tim:

authentication, ? So we are also thinking about this in the context.

Tim:

, could we come up with a universal credential transfer type format, ? Where

Tim:

it can move your pass keys, it can move your verifiable credentials, it can move

Tim:

maybe even your mobile driver's license.

Tim:

That's a very political topic, so it won't go there.

Tim:

But like those types of credentials between platforms and ecosystems and

Tim:

wallets , is a password manager just now gonna become , a wallet, it kind of was

Tim:

the original digital wallet in many ways.

Tim:

Sure there were just , bear data in their bear credentials.

Tim:

But, , we expect password managers to evolve into pasky managers and

Tim:

all these things, so we really wanna think about it holistically as well.

Tim:

And we certainly didn't wanna rush into a solution that dumps

Tim:

a text file out . So, top of mind the feedback was loud and clear.

Tim:

, we knew it was coming and we just wanna make sure we can do it the.

Tim:

Great.

Mishaal:

And one of the other things I wanted to talk about is how exactly

Mishaal:

cross device authentication works.

Mishaal:

And I, I know that's one things that's top in mind for people who

Mishaal:

are interested in paske or wondering how paske replace passwords.

Mishaal:

With passwords you have the password, with you, you can use it on any

Mishaal:

device that you have access to the internet or sign into those apps.

Mishaal:

Whereas with past keys you have the private key that's stored on the device

Mishaal:

and say, the typical example is you have an Android phone and a Windows pc and you

Mishaal:

created an account on your Android phone.

Mishaal:

Private keys on your Android phone backed up to Google Password Manager.

Mishaal:

But your Windows PC is, windows OS with Microsoft Manager.

Mishaal:

And so , how exactly would you use your credential, sort on your Android phone

Mishaal:

to sign into a website that's, on your Windows pc and how exactly does that

Tim:

process.

Tim:

Absolutely.

Tim:

Yep.

Tim:

, so, one of the biggest misconceptions, which I wanna start with is that

Tim:

, the PA key itself, as Christian mentioned, the private key and

Tim:

the MEDA moves across devices.

Tim:

That is not what happens assigned assertion moves, , just like , if you're

Tim:

familiar with , some of the federated login scenarios was signing with Google,

Tim:

? Your Google account credentials

Tim:

It's an assertion that's signed.

Tim:

? So it's, a very similar concept.

Tim:

It's a lot more complicated, obviously.

Tim:

But this is another great example of something that's implemented in the

Tim:

c a layer, which is not something a website needs to worry about.

Tim:

So, , The pattern we'd like to evangelize with it is that users are not using their

Tim:

phone to sign into something on their desktop or laptop every time we imagine

Tim:

as a way to bootstrap the other ecosystem, ? So you can imagine a world where, Android,

Tim:

iOS are already shipping past keys.

Tim:

Windows will be a little bit further behind just different dev cycles.

Tim:

It's a old operating system.

Tim:

So obviously I may have PAs keys on my phone that I don't yet,

Tim:

have a PAs key yet in Windows.

Tim:

So when the day comes, when Windows has passkey support and I wanna

Tim:

sign into a service on Windows, the first time I use my phone, I

Tim:

go through , the pairing process.

Tim:

The linking process for the first time.

Tim:

And then the hope is that as a relying party, you would see that, that.

Tim:

Credential came in from another device, there's actually some metadata that let

Tim:

you see it, and you pop up something that says, Hey, do you wanna actually

Tim:

enroll Windows or this device so that you don't need your phone every time?

Tim:

And then at that point you have a, a PASKY that's syncing in

Tim:

the Microsoft ecosystem and in the, let's say Google ecosystem.

Tim:

And then you never need your phone to sign into that service on Windows again.

Tim:

Right?

Tim:

? So we, hope that's the pattern.

Tim:

That's what a lot of the developer docs on PAs, keys dot, Dave will

Tim:

evangelize because , we don't think it's a great experience that the user

Tim:

has to take their phone out every time.

Tim:

There's nothing stopping them from doing that if they want.

Tim:

But , it's not an ideal experience.

Tim:

And so, the way it actually works, , there's been a heavy,

Tim:

heavy focus on QR code based authentication, ? That's what it is.

Tim:

And it's really not.

Tim:

The only thing that QR code does is allow the devices to link.

Tim:

And we're explicitly saying, linking, not pairing, because

Tim:

it's not like a Bluetooth pair,

Tim:

? There is though actual Bluetooth

Tim:

between these devices.

Tim:

What's happening is when you, scan the QR code you're sending part

Tim:

of a key , to a key agreement.

Tim:

And also you're proving proximity,

Tim:

? One of huge security properties of vital

Tim:

obviously it's plugged in physically.

Tim:

NFC only works on top of it, ? And so, using Bluetooth low energy

Tim:

beacons, , which have a very short, it's.

Tim:

Bluetooth Classic, where it goes into , another apartment.

Tim:

It's a much shorter range.

Tim:

We can actually prove that the phone is nearby to , the client, which would

Tim:

be the desktop in this case which helps check the box of proximity.

Tim:

And what essentially happens is there's every authenticator, so let's

Tim:

call the phone the authenticator.

Tim:

They have a cloud service that actually is, think of it as a big

Tim:

router that can actually help the request get to the phone and back,

Tim:

? , it's to like a web socket model, ? And

Tim:

some information that's shared in Bluetooth advertisements, ble the

Tim:

advertisements between the devices.

Tim:

Obviously they have to be close to each other to see that.

Tim:

And then both parties can actually go establish a secure

Tim:

connection to this service.

Tim:

And then at that point, the same exchange that happens to a USB security key or n.

Tim:

Happens just over that transport.

Tim:

So the official protocol level name for this is called hybrid.

Tim:

Not very exciting.

Tim:

But the way we refer to it more generically is cross

Tim:

device authentication.

Tim:

, it's very, very flexible.

Tim:

, obviously cross ecosystem.

Tim:

You can do this today, windows, Mac, Android, iOS and it's

Tim:

super, super user friendly.

Tim:

Users are familiar with QR codes now, and the nice thing is too, is

Tim:

actually on Android specifically you don't have to do the QR code step

Tim:

every time after you've done it once.

Tim:

As long as you leave the remember me checkbox on your phone side, you'll just

Tim:

click on your phone in the notification.

Tim:

So I'm curious,

David:

On the legacy side of this, a lot of people are going to be trying to share

David:

between say, an older desktop PC and their smartphone, which desktop, PC doesn't

David:

have a camera, it doesn't have Bluetooth.

David:

, are there fallback

Christiaan:

methods.

Christiaan:

Yeah, that's, a good question.

Christiaan:

, I think , there's two things.

Christiaan:

The first thing, I'll quickly just go back to what Tim said, because I

Christiaan:

think it also feeds into this answer a little bit, is early on we spoke

Christiaan:

about PAs keys and how they get synced using Google Password Manager.

Christiaan:

I think there's one important thing we have to call out.

Christiaan:

Passwords in the Google Password Manager are synced to wherever your Google

Christiaan:

password manager was, ? You could even have it on iOS, you could have it on

Christiaan:

Windows, ? You have it on Android.

Christiaan:

PAKEs are fundamentally different because of the security properties that

Christiaan:

we wanna guarantee with PAs, and also , the usability that we want with Paske.

Christiaan:

Pakis are a system provided component, which means if you have PAs on

Christiaan:

Android, They stay on Android, they'll move to your other Android

Christiaan:

devices when you sign in there.

Christiaan:

But your PAs keys on Android is not gonna become available to Chrome on Windows.

Christiaan:

The only way to use it is using this cross device mechanism

Christiaan:

that Tim was referring to.

Christiaan:

The same with iOS.

Christiaan:

You can have your Google password manager on iOS all day long.

Christiaan:

Your PAs keys are not gonna be there right now.

Christiaan:

You have to use your Android phone in order to scan a Q code on your

Christiaan:

iPhone, which will then provide , this local mechanism , for transferring the

Christiaan:

signature over to sign the user in.

Christiaan:

Reasons for that is mostly security.

Christiaan:

There's also another reason there, in terms of app consistency on.

Christiaan:

, iOS Chrome and Safari and your apps running on iOS all use the exact

Christiaan:

same PAs out of the exact same store.

Christiaan:

So users don't have to worry that Chrome is storing Paske over here.

Christiaan:

Facebook is storing Paske over there.

Christiaan:

Safari is storing PAs keys over there.

Christiaan:

No, no, no.

Christiaan:

They're all stored to the iCloud key chain today.

Christiaan:

, so consistency at the platform level was very, very important to

Christiaan:

us when we devised the system.

Christiaan:

So just one thing I wanted to call out, back to David's question, which is

Christiaan:

like, okay, now that there's even more discrepancy here, like a user goes to

Christiaan:

an old Windows device, doesn't matter if they're using Chrome, they're not

Christiaan:

gonna have their PA keys there, right?

Christiaan:

Their past keys is on their Android phone.

Christiaan:

How do they use them?

Christiaan:

, the main issue here is that proximity is critical to the security of the solution.

Christiaan:

If we don't have that local proximity check that we have through

Christiaan:

Bluetooth, it technically means again, that a user can be duped.

Christiaan:

Being fished essentially,

Christiaan:

some person, somewhere in a different country could go try to get the user to go

Christiaan:

to a website, approve a login on a phone.

Christiaan:

And because there is no proximity checks, you are not sure that you're logging

Christiaan:

the device in, that you're looking at, you might be logging the attacker

Christiaan:

in that's, a thousand miles away.

Christiaan:

So to us, the proximity is very important.

Christiaan:

We have b.

Christiaan:

As our main mechanism for doing the proximity today it was a

Christiaan:

lowest common denomin ? It's available in lots of places.

Christiaan:

It's fairly robust.

Christiaan:

It works across, devices.

Christiaan:

We are looking into other alternatives there as well.

Christiaan:

Things that we might wanna do in the future.

Christiaan:

This one is not gonna help for David's question.

Christiaan:

UWB, for example, ultra wipa, even better, in range and stuff.

Christiaan:

But again, that's technology that'll come out in the future.

Christiaan:

Depending on how many users are in this boat, where they have older systems

Christiaan:

that they need to sign in, one might think of other types of local transports

Christiaan:

which we could use to prove proximity.

Christiaan:

There are many technologies available to us, like local network access is one that

Christiaan:

some applications use to gauge whether, users , are physically co-located.

Christiaan:

That's not something in the protocol right now, but it might be something

Christiaan:

that we wanna look at in the future.

Christiaan:

Today we're.

Christiaan:

Users are gonna have to live with one leg in either ecosystem.

Christiaan:

One leg, probably still in passwords for a while on these older legacy devices.

Christiaan:

One leg with PAs keys.

Christiaan:

The benefit of this is to the relying party of the services implementing it.

Christiaan:

The less the user is subjected to passwords, the more scrutiny can we

Christiaan:

subject them to when they do need to log into that legacy system.

Christiaan:

Today we have to allow passwords through as a first class method

Christiaan:

because that's all we've got.

Christiaan:

We can actually start to demote passwords to actually, you wanna use

Christiaan:

a password, maybe you can't log in immediately, like maybe we subject

Christiaan:

your account to in one hour hold.

Christiaan:

Or while we lost verifications to all your other logging devices.

Christiaan:

There's lots of things that we could do if passwords weren't to be treated

Christiaan:

as like a first loss login primitive.

Christiaan:

But we don't have a straight answer today for legacy devices.

Christiaan:

I think passwords plus some additional scrutiny is probably what we're

Christiaan:

gonna have to do there , for a while.

Tim:

Yeah, I think realistically in the short term, and let's say.

Tim:

Two to five years.

Tim:

, the goal is to de-emphasize passwords, ? Start removing them solely.

Tim:

A user that has, let's say three pass keys , may be treated differently from

Tim:

a sign and flow than a user who has one pass key and a password in sms ? The

Tim:

capabilities are there to have very rich, dynamic experiences that can change

Tim:

over time , as these levels change,

Tim:

? Of, of users with pass keys

Tim:

So it's really about de-emphasizing , as Christian mentioned, like you come

Tim:

in, you've used a pass key for a year now three different pass keys

Tim:

from 3D devices, and all of a sudden you come in from a device with a

Tim:

password, ? Red flag should go up,

Tim:

? And , that's all authorization

Tim:

an authentication decision.

Mishaal:

And just to be clear, existing accounts that would've been

Mishaal:

created with username, password, those can be migrated to used pass keys.

Mishaal:

Is that right?

Tim:

It's not automated, right?

Tim:

, if you actually see this on PayPal, I believe they're the most

Tim:

widely known deployment right now.

Tim:

If you sign into your PayPal account with user and password, they're

Tim:

probably gonna do an SMS check.

Tim:

And then if you're on a platform they're supporting, which I believe right now

Tim:

is,, iOS, that's their first rollout.

Tim:

They will actually pop an interstitial that says, Hey, upgrade to a pasky.

Tim:

? So , the user still has to do something.

Tim:

The relying party has to do something.

Tim:

We get asked a lot, can we just , bulk enroll a bunch of PAs?

Tim:

I think there are some things we can do to make that easier, which I

Tim:

think , we're starting to look at.

Tim:

But , it's unfortunately not like just this, flip a button and they go.

Tim:

But you know, in theory it's a one time thing for each account.

Tim:

So, Another

Mishaal:

question that I had is what will happen to the existing trove of

Mishaal:

security keys that people are using?

Mishaal:

, will you still see security keys being used for authentication?

Mishaal:

Cause I know when you're.

Mishaal:

Using your phone, you can do biome authentication or a pin to

Mishaal:

say, I want to use this past key.

Mishaal:

And where will we see security keys being used in that process?

Mishaal:

I

Christiaan:

mean, , I think a unique perspective on this because that's the

Christiaan:

question that we have to ask for Google accounts today, ? We have lots of users

Christiaan:

using security keys on Google accounts.

Christiaan:

We are fully , marching ahead in order to implement PAs keys

Christiaan:

on Google accounts as well.

Christiaan:

And then the question becomes , what happens to security keys

Christiaan:

now, I think from the get go.

Christiaan:

, our thinking has always been , as we're moving on, web and platform

Christiaan:

credentials and toskey that we didn't wanna leave security keys behind and

Christiaan:

treat them as second class citizens.

Christiaan:

So today, when a website, when a relying party or developer supports

Christiaan:

PAs keys, they have to go out of their way to not support physical security

Christiaan:

keys, ? The way that I think about this is if you have a five two compatible

Christiaan:

security key, that five two compatible security key can store PAs keys,

Christiaan:

? They might only be on that single device.

Christiaan:

They're not synced to a cloud or something like you might have with your

Christiaan:

phone, ? But your PAs key now lives on your physical security, and you should

Christiaan:

be able to use that exactly the same way that you use your phone now on the

Christiaan:

phone, you authenticate by touching your fingerprint or typing a pin.

Christiaan:

On a 5 0 2 security key.

Christiaan:

I mean, I have some security keys with fingerprint readers on them, right?

Christiaan:

That's stuff that exists.

Christiaan:

If you don't have one of those most of the 5 0 2 security keys out there

Christiaan:

can authenticate using a PIN code.

Christiaan:

So you can set a four digit pin code.

Christiaan:

And the nice thing there is, it's not like a password, it's

Christiaan:

not sync remotely anywhere.

Christiaan:

It's just on your security key.

Christiaan:

And the same PIN code can be used for all the websites for which you have

Christiaan:

PAs keys on that security key, right?

Christiaan:

, so to go to Google and register a fighter two security key, or to go to Google and

Christiaan:

register a, physical phone in the future as a paske should be exactly the same.

Christiaan:

And for users who think that they're better served by having the physical

Christiaan:

security key, Maybe it's because they're afraid they might lose their

Christiaan:

phone, they wanna have a backup.

Christiaan:

Maybe it's because it's a, specific type of high risk user who's worried

Christiaan:

about, having PAs keys on phones and they prefer having a security impact.

Christiaan:

We're essentially opening security support up to much, much, much wider array of

Christiaan:

websites through the PAs key initiatives.

Christiaan:

Because websites who used to look at this and say, securities are teenage,

Christiaan:

I'm not interested in implementing it.

Christiaan:

PAs keys are great.

Christiaan:

I wanna implement that automatically.

Christiaan:

Those websites will now get security key support almost for free, which I think

Christiaan:

is , a very nice side effect of the way , the protocols been architected.

Tim:

Yeah.

Tim:

And , ? We plan at least on the window side, a phone and a

Tim:

security key will always have equal footing, ? , any remote device will

Tim:

show up , on the windows, hello screen.

Tim:

Security key will still be there.

Tim:

We're not planning on deemphasizing it at all.

Tim:

We have in the enterprise space, and I hate the word enterprise, but like , the

Tim:

more work centric things we expect security key usage to actually increase.

Tim:

And so that will remain , an option as it is today.

Mishaal:

We're getting close to time.

Mishaal:

So, I'd like to give you both an opportunity to do a quick outro.

Mishaal:

So where can people go to learn more about past keys as well as, follow you online?

Tim:

Yeah.

Tim:

So actually, as part of this initiative, one of the things that I think we.

Tim:

I shouldn't say fail because everything's a learning process,

Tim:

but , in this particular iteration of this technology I think we, were able

Tim:

to come together and have developer resources available pretty quickly,

Tim:

? Comprehensive ones, right?

Tim:

there's a lot of resources that happened over the years.

Tim:

With Web off and other things, but there's 10 different sites to go to.

Tim:

And they all do different levels of detail and they don't

Tim:

necessarily pull together a story.

Tim:

So that's where Pass keys.dev came from.

Tim:

That's a collaborative effort between multiple companies

Tim:

throughout Fido and w3c.

Tim:

That's a community effort.

Tim:

All the code is on GitHub.

Tim:

You can see pull requests.

Tim:

You can submit changes, ? We want keep it as open as possible.

Tim:

It's more or less governed through.

Tim:

A group called the W3C Community Adoption Group.

Tim:

If you are a developer and you have developer feedback on pakis.dev under

Tim:

about, there's links out to that group, you can join that free of charge.

Tim:

And that's where , we take in feedback and relay it to , the actual working groups

Tim:

and even the platforms and other things.

Tim:

So I would highly recommend you bookmark pakis.dev at a minimum.

Tim:

It's got a great device support matrix that , we literally update every week

Tim:

with this new and flag is supported.

Tim:

So, shameless shameless brag though, something I worked on,

Tim:

but was super happy with it.

Tim:

And , we've gotten a lot of great engagement on it.

Tim:

On Twitter.

Tim:

I don't know if I hate saying that anymore, but I'm Tim Capal on Twitter.

Tim:

I still use both.

Tim:

And then on Macon what is my thing?

Tim:

It's like a whole Tim Kali InfoSec exchange.

Tim:

So we could probably put that, it's actually on my Twitter.

Tim:

It's probably the easiest place to find it.

Tim:

. Christiaan: And then , from our side,

Tim:

We also have.

Tim:

Some documentation over on the Android side.

Tim:

I do realize that it's not complete yet.

Tim:

, at this point we are working on that actively, but if you go to

Tim:

developers.google.com/identity/pas keys you can find our documentation

Tim:

and we'll be updating that.

Tim:

As more functionality gets pushed out there.

Tim:

There is a whole lot of things happening on Android with PAs over the next year.

Tim:

We've already publicly indicated that we want to support third

Tim:

party pasky providers , in Android.

Tim:

That support will be coming next year.

Tim:

There is a whole new.

Tim:

Way for applications to access pakis things, that be, coming out early

Tim:

23, towards the middle of 2023.

Tim:

So lots of activity and everything essentially will be

Tim:

published on that, developers of google.com/identity/pakes website.

Tim:

And then of course, on, on Twitter, I haven't figured out

Tim:

how to make Master on Work.

Tim:

I tried an instance that never sent me the email to set up

Tim:

my password, so not there yet.

Tim:

But on Twitter, you can follow me at Christian with two as brand.

Tim:

So if you're interested, usually if something happens on the Android

Tim:

or on the Google side, I tweet about that pretty, pretty quickly.

Tim:

So if you're interested in anything happening on Android or Google with

Tim:

Pakis, feel free to gimme a follow on.

David:

And thank you both for joining us.

David:

There isn't a great Esper plug because we don't really do anything with past keys,

David:

but this has been immensely fascinating.

David:

The evolution of the password.

David:

I mean, obviously we all know that passwords are bad.

David:

I think either for the right reasons or wrong reasons, everybody hates passwords.

David:

So I'm actually curious about one thing, and this is a bit of Android

David:

esoterica Christian maybe, you know, but Tim maybe you know as well.

David:

So when it comes to two-factor authentication, everybody's got a little

David:

bit of their spin they like to put on it.

David:

I've always found Google's to be not unique, but it's the

David:

only time I've seen it used.

David:

Google

Tim:

uses a two digit

David:

number matching system.

David:

You get three numbers to choose from.

David:

Do y'all know what the philosophy or logic behind that is as compared

David:

to a six digit confirmation code?

Christiaan:

that, that's a great question..

Christiaan:

Well, I mean so much to say about that, right?

Christiaan:

So, I think in general, sick digit confirmation codes is necessary when

Christiaan:

you have a one way communication architecture, like in the old way

Christiaan:

where you authenticated using SMS otp.

Christiaan:

So one time password sent via sms, ? It's a one way communication channel.

Christiaan:

Google sends your phone, then from the phone you type it back into Google, but

Christiaan:

I mean, you're not replying back on the channel that you got the code from, right?

Christiaan:

So in order to prove to Google that you got the right code, six digit

Christiaan:

codes is usually the standard for that, which is also the same standard.

Christiaan:

We ended up using mostly Fort OTP codes generated by applications, ? So

Christiaan:

you have like an app like Google or something that generates TTP codes.

Christiaan:

Usually six digits is from an entry perspective, that was good

Christiaan:

enough so that we can say, well, if someone entered that code, chances of

Christiaan:

someone just like randomly guessing your code, probably pretty slip,

Christiaan:

? So six digit is where we had it.

Christiaan:

Then we moved away from that and we moved to push based authentication systems

Christiaan:

where we sent a message to your phone.

Christiaan:

You reply on the phone directly by saying, yeah, it's me.

Christiaan:

Technically no code is needed there.

Christiaan:

? When you say yes on that particular device, , you can go cryptographically

Christiaan:

from that device back to Google and say, the user definitely

Christiaan:

saw this prompt on their phone.

Christiaan:

We know we sent it to the right phone.

Christiaan:

You send that message back, you can append any length code essentially that you want.

Christiaan:

There might be a cryptographic signature that the companies that, so

Christiaan:

there is no need in that particular example for showing any codes.

Christiaan:

Apple is interesting in their implementation.

Christiaan:

They would do the push, but then they would also still show

Christiaan:

a code that you have to enter.

Christiaan:

I mean, from our perspective, , that's not really, super required.

Christiaan:

And in most cases, when you log into Google, the yes on your

Christiaan:

phone is all you have to do.

Christiaan:

However, in certain cases when logging into Google depending on leg

Christiaan:

schedules and other things, we might also in addition, show you these

Christiaan:

two digit numbers and have three of them that you have to pick through.

Christiaan:

The philosophy behind that is essentially saying that it's the same

Christiaan:

as this Bluetooth bearing thing, ? If you're on your car and your current

Christiaan:

comparative Bluetooth devices together, usually the device will show the same

Christiaan:

code and say, Hey, just be sure that you can see the same code on both.

Christiaan:

I mean, who checks it, right?

Christiaan:

Everyone just clicks past its horrible ux.

Christiaan:

But the point there is on the Google side, we wanna be sure that you

Christiaan:

are logging into the right device.

Christiaan:

You're not accidentally logging in some one other's device that

Christiaan:

also just happened to, at the same time, initiate the logging request,

Christiaan:

having your username and password.

Christiaan:

And when you say yes, you're actually approving their device and not your own.

Christiaan:

They would technically have a different code on their device,

Christiaan:

a different two digit code that we displayed on your phone.

Christiaan:

So this matching here is to weed out, an attacker that just happened to, at

Christiaan:

the same point in time, maybe they're sitting next to you in startup, they're

Christiaan:

watching you log in, and then they did enter exactly at the same point

Christiaan:

that during enter, when you approve on your phone, who knows which user

Christiaan:

device you're actually gonna approve.

Christiaan:

Now it's not foolproof, ? There are still ways to get beyond that.

Christiaan:

If you're a sophisticated attacker with a man in the middle, you can probably

Christiaan:

defeat some of these things as well.

Christiaan:

But at least it tries to weed out 99% of those types of timing

Christiaan:

attacks, where these codes would then allow only the right device to

Christiaan:

be logging and not the wrong device.

Christiaan:

So, a little bit of a long winded answer, but there is method in the

Christiaan:

madness here, but in most cases, users wouldn't even see those.

Tim:

So we, I knew there was, we had, we had something, so , for

Tim:

our enterprise customers, right?

Tim:

Azure ad we had the same thing.

Tim:

We had number matching.

Tim:

we actually now make the user type in the number because the number of

Tim:

users that were correctly selecting a random number because it popped

Tim:

up, was insanely high, right?

Tim:

The probability is still pretty good.

Tim:

So we actually have the option now, admins can turn on.

Tim:

You actually have to type the number for us.

Tim:

Microsoft employees we have to type in the actual number.

Tim:

You can't just select it . So it, funny to watch the

Tim:

progression , of that experience.

Tim:

We call it number.

Tim:

That's,

David:

that's fascinating because my anecdotal experience, and I know

David:

probability makes, means this means nothing, is that I get it wrong every

David:

time I try to guess it instead of looking over at my phone every single time.

Tim:

Least . Yeah's funny.

Tim:

Yeah, I, I think we actually did a blog post that has some of the numbers.

Tim:

I'll see if I can dig it up.

Tim:

. Yeah, I knew

David:

there was a good story there and it was a good story.

David:

Thanks for sharing, Christian, because I don't think many Android users would

David:

have any idea why that system exists.

David:

So hopefully they learned something and hopefully they learned a lot today.

David:

Talking about paske.

David:

If you're not interested in personal security credentials or credentials

David:

otherwise, but securing devices specifically, come talk to us at Esper.

David:

We do Android device management better than most places.

David:

Every other place, honestly, esper.io, you can visit us and Michelle and I are

David:

both on Twitter and you can find us there.

David:

Thanks for listening everybody, and we'll see you next time.

All Episodes Previous Episode

Listen for free

Show artwork for Android Bytes (powered by Esper)

About the Podcast

Android Bytes (powered by Esper)
A weekly show that dives deep into the Android OS
Android Bytes (powered by Esper) is the podcast that dives deep into the engineering and business decisions behind the world’s most popular OS. https://www.esper.io

Android powers over 3 billion devices worldwide and is the platform of choice for over a thousand companies. You’ll find Android on smartphones, tablets, watches, TV, cars, kiosks, and so much more. How does Google architect Android to run on so many form factors, and how do companies fork AOSP to make it run on even more devices? These are the kinds of questions the Android Bytes podcast considers each week.

Join cohosts Mishaal Rahman and David Ruddock, two journalists with extensive knowledge covering the Android OS platform and ecosystem, as they speak to system architects, kernel engineers, app developers, and other distinguished experts in the Android space.

Get in touch with us at Esper.io if you’re looking to use Android for your product — we have the experience you need.

About your hosts

David Ruddock

Profile picture for David Ruddock
David is the Editor in Chief of Esper, and cohosts Android Bytes. David spent over 10 years as the Editor in Chief of Android Police, where he reviewed more phones than he'd care to admit, broke dozens of exclusive mobile industry stories (and also, phones), and ran one of the web's most vibrant Android communities.

Mishaal Rahman

Profile picture for Mishaal Rahman
Mishaal is the Senior Technical Editor at Esper.io and a cohost of the Android Bytes podcast. At his previous role as Editor-in-Chief at XDA-Developers, Mishaal was at the forefront of Android tech journalism, breaking story after story on new OS features and platform changes.