What is a passkey and why should you care?

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
David (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 myco-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 reallygreat folks on to talk about a
topic that, honestly, I know nothing

Tim (00:21):
about

David (00:22):
PA

Tim (00:22):
Keys.

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

Tim (00:25):
to introduce our guests?

Mishaal (00:27):
Thanks David.
So on today's episode, we invitedTim Capal and Chris John Brand.
And I wanted to give you guys, , both theopportunity 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:44):
or Christian?

Christiaan (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, , fighterrelated initiatives here at Google for.
Probably a little bitover 70 years, , so far.
And before I came to Google, , I hada startup and we were also part of
the Fido Alliance and working thereeven before I formally joined Google.

(01:05):
So I have been, , , in thisspace for quite some time.
, our goal was always to bring thistechnology 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 ofother companies, , Tim from Microsoft
here, will tell you a lot more abouttheir, , perspective on this as well.
But, essentially there is a whole bunchof companies part of this thing called

(01:26):
the Fido Alliance, Microsoft, thethird Apple is there, Google is there a
whole bunch of other companies as well.
We've been working inthis space for four years.
But the technology was niche.
It was for users who had very specifictypes of hardware called Fido, security
keys, and other types of technologies.
, and with past, we are reallybringing that technology to everyone
and making everyone online safer.

Tim (01:48):
Thanks, Egen.
Yeah.
Hi everyone.
My name is Tim Capal.
And I work at Microsoftas a standards architect.
So I actually work heavily in theFido Alliance with Christian and
with Google as a partner as well.
And also , a lot of this technologyis also designed in the w3c, ? So
that's where a lot of the browsercomponents come into play.
I joined Microsoft smack d inthe middle of Covid March, 2020
when the world was shutting down.

(02:09):
And so before that, I actuallyworked in network identity, ? So
wifi network wifi, roaming, wifiidentity, all that fun stuff.
And I've had a passion forwanting to kill passwords since
I kind of started that journey.
So, , made some progresson the network side, right?
There's still, some things that needto be done there, but was super excited
to start working on this problem atMicrosoft as well, albeit at a different
layer, , , on the web for apps.

(02:30):
But similar problems exist, passwordsare , one of the top problems with.
All, all, all cybersecurity issues these days.
So, super, super excited to collaboratewith Google and Apple and the vital
alliance , on this whole pasky thing.

David (02:43):
Yeah, my passion for killing passwords, I have never
seen it put so eloquently.
I

Tim (02:48):
love it.
So, yeah, I had a nickname.
The customers at my last job gaveme the nickname TLS Tim, because the
solution on the network side for notusing passwords is TLS certificates.
And I got a little worked up whenI was talking about it as usual,
like, let's kill the passwords.
And so now my new nickname, I wascoined on Twitter as Tim Kaki.
So , there's alwayssome nickname somewhere.

(03:09):
Nice.

Mishaal (03:09):
So I think we all have a general good understanding of why
we want to kill passwords, , amongus , but some people may not be as on
board or it might be as familiar withwhy you want to go ahead and do this.
So you want to convince peopleto switch away from the password,
you need to convince them thatwhatever you're building, the
alternative is better in every way.
It has to be not only safer, ithas to be as convenient, if not
more convenient, and it also hasto be, easy to understand and use.

(03:33):
Why don't you just start off by tellingus what exactly is wrong with passwords,
what makes them inherently more insecurethan whatever you're working towards right

Christiaan (03:40):
now?
, I'll jump in.
I mean, so, so many thingswrong with passwords, right?
There are shared secrets for one, ? Youknow, 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 hardto reverse, and there is a whole bunch
of reasons why passwords , as a sharedsecret model , has limits , on what you

(04:03):
can achieve from a security perspective,
if that other end of your passwordgets 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 123 across various websites, Let's be
honest, most users do, or at leastuntil password managers became a thing,

(04:26):
that was what everyone did, right?
So now it means that when yourpassword on website X is breached,
your password is breached everywhere,? Because it's essentially the same
password that you keep reusing withthe same username, password combo.
So, remote end breaches, bigproblem with passwords password
reuse, giant issue there.
And then of course, , my favoritething to hate about passwords.

(04:46):
They're super easy to fish.
And I think that has reallybeen , what at Google we've been
interested in solving ever sincewe started on this journey, right?
Our journey of the FightingAlliance didn't start because
we wanted to kill the password.
It started because wewanted to kill fishing.
Back in 2009.
A bunch of, tech companies, Googlebeing one of them was subject to

(05:06):
the Operation Aurora Hacks, which,By this point, it's pretty public.
, and how all that started again iskind of like with Phish, right?
Because usually theseattacks start with Phish.
We wanted to solve that problem.
We still, we want to solve that problem.
, the technical solution tothis was essentially what
became the PHY two F standard.
We first implemented it internallyfor our own workforce and then we

(05:27):
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 arewe 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 onout, but really at that point it was
like, why are we even doing passwords?

(05:48):
Can we just stop doing passwordsand simply rely on the technology
that we now have in FI Alliance?
, which essentially gets us now from , likeI 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, itneeds to be easier to use.

(06:09):
It needs to be faster.
And that is, I think, what we finallyhave with the current set of standards,
which essentially collectively , wecall Paki uh, over to 10 because I'm
short term, have a lot more to, to talk.

Tim (06:20):
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 thatCHIPS now has biometrics, ? , and a secure
element and all these pieces that , , youcouldn't weave a story together for
both a user experience standpoint andfrom a security standpoint across the
board, ? There was all this fragmentation.
So we're now at the point where even lowend devices have pretty high security

(06:41):
capabilities compared to , even fiveyears ago, ? So , the fact that if someone
with a $2,000 phone and a $500 phone canall 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, Securitykeys with a thing, right??
The little, USB or NFC dongle.
And that has cost and users lose them andusers don't understand them and there's

(07:05):
no good name for them, ? All these thingsthat compound to the point where it's
just another annoying thing that itgives you that you have to carry and use.
. And the most ironic part aboutthe security key thing nowadays
is like everything else that'son my key chain is, either on my
phone now or moving to my phone.
The only thing I have left on my keychain, I have a security key, but

(07:25):
I'm a nerd, so let's wipe that out.
But , my mailbox key, that'sthe only thing that's like
analog and on a key chain.
So telling users to secure theirdigital life, you have to carry
this thing on your key chain.
that's a hard sell, especially fromall these same companies that are
working to give them digital access tothe same credentials on their phone.
I love your

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

, Mishaal (07:47):
there's varying, varying degrees of how closely people follow best
practices , or what people say is bestpractices for securing your online life.
? Do you use multifactor authentication?
Like what kind of multifactorauthentication do you use?
SMS based, app based,security key, et cetera.
And biometric authentication, all of theseseem like they're just larger and larger.
Band-aids being applied on topof the foundation that was,

(08:09):
inherently insecure, passwordbased authentication as a primary.
And now , pasky seems like you'reripping all those band-aids off
and saying, okay, let's restructureeverything from the beginning.
, let's rethink completely how we thinkabout primary authentication and start
from a more secure model from the ground.

Tim (08:26):
Is that like,

Christiaan (08:27):
I think that that's the whole point, right?
At some point, like I think up untilmaybe, I don't know, 2005, 2006,
whatever, like passwords were okay, right?
We all had the same password in whichwe typed in and things were okay.
Then we started introducingpassword complexity requirements.
Then we started introducingpassword rotations.
Then we started to implementmultifactor on top of this, ? It
really became unbearable, right?

(08:48):
To sign into something new.
Every time I have to create a newaccount, which nowadays you have
to do for everything online, even.
Technically shouldn't even need an accountyou 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 cumbersometo deal with them.
, and has happened with the bandaid?

(09:09):
It made the usability of passwords worseand worse and worse and worse to a point
where, , most of these, I I look atsome family members here , who deal with
online account, their strategy is to bangsome numbers on the keyboard whenever
they need to create a new account.
And then when they need to resignin, they go through the password
reset email link because , that's theonly way that makes sense to them.
And I think , if that's where weare that's really a broken place.

(09:31):
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 (09:42):
Right.
the Goal is that we hope thisis 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 levelcredential that my mother can use.
Everyone I know can use that has reliableand consistent across platforms , and
works across platforms, That's one of thebiggest core things we did with this is

(10:02):
that this works across platforms, right?
? It can't be, this only works withApple and only with Google and only with
Microsoft because one of the challengesthat 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 biometriccenters and tpms and secure elements,
all these great security features.
When the user got a new device, theyhad to default back to a password, ? So

(10:23):
we, had actually all the pieces, wehad everything out there, but we needed
to pull it together into a story thatwas more password like, while having
all of the best security propertiesof this newer phyto technology, right?
So that's really , what PAs keys gets us.
If we think about passwords being aone and, , this state for the past few
years where all these devices have thecapability as 50, we're getting to a

(10:44):
hundred now where you can actually trulyno 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 timewith you across your devices and et
cetera, ? , that was the missing piece.
, and that's what PAs keys bring to us,

Mishaal (10:58):
right?
And part of.
challenge now from migrating frompasswords to past keys is that
everyone knows what passwords are.
They understand how they work causethey've been around for so long.
. I've had trouble getting my dad to usea 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 conceptand , there's not really much, until

(11:20):
that announcement that happened backin 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 becausea lot of the work was being done
through , these standards bodiesand behind the scenes with all these
, technical meetings that like you bothwere probably extensively part of.
So, I wanted to get everyone on the samepage and go through some definition.

(11:41):
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 (11:49):
Alliance?
Right.
Happy to do that.
Yeah.
So, the Phyto Alliance isessentially a consortium.
It is a group of companies whocame together with a goal in mind.
And the goal that we had in mind wassimplify and strengthen authentication.
. That was ultimately the goal.
Originally it started primarilylike I said, because of certain.

(12:09):
Issues that was prevalent even inmultifactor authentication, Even if you
have an account that's secured with auser 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 MicrosoftAuthenticator that gets generated
technically those types of authenticationmechanisms are still feasible.

(12:31):
If you have a bad guy sitting in themiddle somewhere and they can trick you
into typing your password into their.
They can probably trick you intotyping your OTP coding there as well.
And we've seen these typesof attacks in the wild.
So multifactor authentication asit stands today is no match for a
SP fisher for someone who's reallyafter your particular account.
And actually it's become easier andeasier to conduct these attacks at scale.

(12:53):
There is tools out there andX , is one particular I think
great example or bad example.
I dunno.
It depends on which way you go of areverse proxy that is set up to steal
credentials, ? Very, very easily.
You can do it at scale.
And pretty much deployed MFAtechnologies are susceptible.
Fighter Alliance was set up todevelop the next generation of MFA

(13:16):
that would not be susceptible tothese types of phishing attacks.
Started with a second factor.
It started with a physicalthing called the security key.
Then that became, well, why don't wetry 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 joinedup in the FI alliance, I mean,

(13:37):
this didn't happen overnight.
There was a bunch of companies in there.
Google joined about a, I think abouta here or a couple of months after Fi
Alliance inception, . Microsoft joinedlater 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 callin, Fido language relying
parties, those who be your meta,
.It would be your sales force sap, like , the typical

(13:59):
companies who would use the te.
You also, of course, for anythinglike this , to really succeed,
you need the platform providers.
The folks who provide the computingplatforms, 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

(14:20):
systems that users find themselves on.
You want this technology bakedinto the platforms directly.
You don't want to have to haveusers 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 ishow do we even explain this to users?
That's the cool thing about theway that this is architected.

(14:41):
You don't really have to.
. The goal with Fido and with Paki are whenthe user uses their application in the
way that they use it today you can surfacethe user a prompt and say, Hey, you
used to be signing in, using passwords.
Do you just wanna use yourface next time or your.
That's all you reallyhave to ask the user.
Now, the cool thing is, eversince the advent of the iPhone 5S
users have become accustomed tousing biometrics to log into apps.

(15:03):
I mean, if you have a banking app onyour iPhone today, chances are when you
open that app up, you're gonna supplyyour face or touch your fingerprint,
?, ? That is where we start with PAs keys.
We then do a whole bunch of things alittle bit better than the, status quo.
Because when you get a newdevice, passkey continue to work.
You don't have to fallback through passwords.
When you wanna sign in on another devicethat doesn't have a passkey on it, you
can use , your phone that has your passkeyin some wireless capacity in order to

(15:27):
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 thepoint where, I just signed into
my app using my fingerprints.
That is exactly what PSS are and more.
Right.

, Mishaal (15:46):
I do understand the goal and that's part of what
makes it as convenient, if notmore convenient than passwords.
The fact that users don't really have toknow the underlying technology at all.
But I do still think it's interesting totalk about, what has to be implemented
by, website developers and platformdevelopers such as, Google, Microsoft.
So, some of the other terms thathave come up, when you search or when

(16:06):
you read up on PA keys are the webauthentication api or in the client to
authenticator protocol, the 5 0 2 project.
, can you explain what each ofthese are, , who has to implement
them or utilize them and so on?

Tim (16:18):
Yeah, absolutely.
And the reason that there's actuallytwo different things, ? Wen and Ctap,
you, , you expanded already is actuallyto divide the labor a little bit, The
nice thing is a lot of the complexityin 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 interactswith other devices like a security
key or even your phone in the case ofinteracting with a desktop operating

(16:40):
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 allthat 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 theprimary 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

(17:03):
device or on the other device.
And the nice thing is like an eBayor a PayPal as the website don't
necessarily need to worry about whereit is, ? It could be on a security
key, it could be on a remote phone, itcould be on the local device , all of
that plumbing and even routing is allhandled by the underlying platform,
?So ctap is an incredibly complicated protocol.
I'm not gonna sugarcoat that,but only a few, companies really

(17:24):
need to actually implement it,which is great, ? , it removes so
much of the developer complexity.
, for services.
, . The only difference really betweena website and an app is generally
what happens is , the operatingsystems where the apps run,
?The app platforms try to mirror the browser API as closely as possible,
? So it, is a little bit differentif you're a web developer versus
a Android app developer, There'sdifferent functions you have to call.

(17:45):
Obviously one is native code.
But , what you'll find if you look atsome of the developer documentation
is that most of them mirror theweb 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 , prettyquick, pick up for a develop.

. Mishaal (18:01):
And then onto the, topic of the day itself, pass keys.
So from what I understand, pass keys isthe marketing name for Fido credentials.
Can we actually talk about whatexactly is a Fido credential?
How is it created and storedusing, say Android or Windows
as an example?
Yeah.
Do you want, can we, should wetalk about the term real quick?
Just the people?

(18:21):
Yeah.
Talk about the term.
Yeah.
So, the interesting thing aboutPAs keys obviously it's a play on
We needed something that we think overtime users will pick up, ? , Like,
, what the hell does Bluetooth mean?
? Bluetooth didn't actually meananything, but people heard it
and used it and it caught on.
We think passkey actually, if a user hasno context over time and they constantly
see like, oh, I'm unlocking with myface, I'm unlocking with my fingerprint.

(18:41):
, and I saw this term passkey, we trulybelieve that that will stick and that
will just become the common term tothe point where we also, phyto Alliance
introduced an icon you've probablyseen as a little person with a key
that we hope that eventually, let'ssay 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 somekind of biometric, prompt, or selection

(19:04):
screen, ? ?, that is really the goal.
And that's all , we can really ask forfrom relying party developers ? We want
you to have either this autofill UIthing, which we can talk about later,
or a button that's assigning with thepasky, with the icon, +, and away you go,
?No more worrying about , should I put windows?
Hello?
Should I put touch, id, shouldI put face Id the goal is
to have a very neutral term.
, I've actually since day one beenthinking about this in the same

(19:25):
way that, a payment terminal.
Most users nowadays tend torecognize 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, includingmy mother, which my mom is a
great test for all this stuff.
So, that was kind of thethinking with the icon.
Can we get to something similar on theweb where users just see this and they
know they can get in, in a certain way?

(19:47):
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 startingto see relying parties use it.
You'll start to see itacross the platforms.
know, You'll certainly seeit in Windows at some point.
And , variations of it being usedin 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

(20:07):
complicated, ? Twitter is a big, in manycases, a vacuum of tech people, ? With
which sometimes we're, having ourown , our own debates with ourselves.
When you start getting into, , technicalfolks, ? We can describe past key or
past keys as two buckets, One is justthe credential type, ? It's this name
of this thing that you use to sign in.
And , that's how wegenerically refer to it.
We say pass keys or a pass key, ? We'retrying not to say passkey by itself,

(20:29):
cuz , it's is not a protocol by itself.
, it's just another name for.
The credential.
But then , when we talk about all thesenew things that Christian touched
on, these other experiences we broughtalong to make PAs keys easier to
use, like the AutoFi ui there's abunch of things we've done including
the cross device authentication.
We've kind of casually also referred tothat as PAs keys, ? As an experience.
. , and so maybe it's our own fault forof using it so casually, but , we've

(20:51):
generally been trying now to saylike, oh, you support the full pasky
experience and that means the user doesnot have to have a password at all.
You allow them to solely sign upand 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 andthat , you're not restricting cross
device or those other things,

(21:12):
?, , and ideally we would love you to use the term and use the icon, ? So
those the three things that make upwhat 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 splitthose up, into what makes this whole
picture versus the credential name.
So we ended up in this littlearea, but I think now , we're
able to kind of differentiatewhen we're, talking about it.
Yeah, I did notice that while I wasgoing through the documentation , it's

(21:34):
used interchangeably, whereas , inone sense you're talking about , the
private key, public key combo as a passkey and then also the whole process,
, the cross device authentication.
And , the multi device Fidocredential experience, all of that
is encompassing the past key, ? Andso it was a little confusing at first,
but I think , there's some excellentdocumentation that really helps,

(21:54):
, disambiguate what's going on here?
So I kinda have to talk aboutnow about the experience of
creating and storing a passkey.
So, as I just mentioned, , when yougenerate a passkey on a device, say you
have an Android phone, you go to a websiteon Chrome that supports pass keys and
you generate a passkey, what exactly isbeing created, , what's stored on your
device and what potentially could besynced to say Google Password Manager?

Christiaan (22:17):
Great.
, how did you take that one?
So essentially a pasky consistsof a record which has some
metadata associated with it.
, and that's really important and we'lltalk about that in, just a second, but,
Historic password in a password manageressentially is all based on heuristics,
?There is a password there.
There is usually a usernameassociated with that password because
that's just how we use passwords.

(22:38):
It's this combo of username, password.
And that's what password managersknow s are a little bit different.
When a website wants to create a pasky fora particular account on that website it
sends a bunch of metadata to the systemin order to create this pasky first.
It sends some kind of like a we callit the, old style of user name, right?
And this is mainly there because for awhile there websites are probably gonna

(23:02):
need you support users coming in withboth user and password combinations
and PAs, you might be logging in froma, I don't know, Samsung television,
which doesn't support pasky yet,or whatever the case might be.
So for a given account users willprobably have to live in this world
where passwords and PAs coexist.
So, The first thing that the websiteneeds to tell , the system or the app
needs to tell the system to create aPAs is what's the account name that's

(23:24):
associated with this particular pasky.
And that could usually bewhat we call the username.
So usually an email address doesn'thave to be, but that's kind of like
the first thing you're pausing.
Then there is also a friendlydisplay name that now exists,
which you can pass in.
For example, my Google account,I have a Google email address.
I have a display nameassociated with that account.
When I tried to sign into GoogleGoogle tells me, hello Christian

(23:44):
brand with a space in between witha nice capital C and a capital B.
And then my email address is shown.
Underneath, almost like, it's kindasubservient to this main display name.
That's all information that you canpass in when you create a pass key.
There is other types of informationthat you can also pass in as a
developer kind of like a handleto this particular credential.
If, you need a way to associate that,this will not be displayed to the user.

(24:06):
The display name and the usernameare things that the user will see.
And then the spec, there's also theprovision for a icon or a picture.
, if I wanna sign to my Googleaccount and I have multiple
accounts, Google will show me.
Display name, username, and alittle profile picture for each
of my accounts that I have.
We wanted to mimic thatover in Pasky Land.
So Pasky technically have the abilityto show the user a display name, a

(24:27):
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 somethingthat 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 onceyou pass that in, you get.
A public key, ? That is the thingthat you now keep on your side.
And remember, early on in the podcast,, we spoke about how passwords are bad

(24:49):
because they're symmetric secrets.
PAs keys are great becausethey're not symmetric secrets.
They're asymmetric in nature, whichmeans the public key, which you as the
website now keep that you can use tomathematically prove that the user had
the corresponding private key, whichis essentially what the PAs key is.
The PAs key is a private cryptographickey that's stored on your device, which
is generated during passkey creation.

(25:11):
You now have that private key.
Public key is what the websitekeeps in order to validate in
the future that the user stillhas access to their private key.
But the private key neveractually gets sent to the website.
The website only knows the public key.
If something bad were to happen at thatwebsite and all the public keys were to
leak out, nothing bad happens, right?
Public keys get leaked out.
They're public, they're calledpublic keys for a reason.

(25:32):
, there's nothing that someone can do withthose 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 haveaccess to this particular credential.
So power key is display line, username, 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 fightercredentials, these PAs keys that

(25:56):
you now have on your phone, they'reso valuable that we decided that we
just have to back them up for you.
? We don't want to leave them just on yourone device, because inevitably you're
gonna buy a new phone, or your phone isgonna break, or you're gonna lose it,
and you're gonna have to, grab a new one.
And what happens to all yourpakis, ? In the old school way
of thinking about biometrics,the answer was, well, it's easy.
We just have the user fall back to theiruser M and their password, their m.

(26:20):
We don't want that for Paske.
We want the user who up Stepss intothe world of PAKEs to stay there,
never inheriting to fall backto passwords unless they're on a
device and don't support PAs keys.
But I mean, that problem willhopefully go away over time.
So the thinking is like we takeyour 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.

(26:41):
So although they're backed up tothe Google Cloud, Google actually
never learns your PAs key.
We can't decrypt it.
The only thing we do is we storethis encrypted blog for you.
And if you show up on a new device andyou can prove to us that it's still
you by signing into your Google accountand perhaps performing an additional
ceremony for PAs keys in particular,you have to both have access to the
Google account and you have to knowthe lock screen, how you unlock your

(27:04):
previous phone that you had the pasky on.
If you can do all of that, we'lldecry the pasky locally for you on
your Android device and then youcan continue where you left off.
So yes, these things , are encrypted.
There is metadata associated , andI'll say the last thing on this.
The reason why there is metadataassociated with it is when you go to a
website and you wanna sign in there andyou don't know whether you have a paske,

(27:24):
you can't remember, like who knows whatthey used last time that they signed
into a particular website, When youarrive at this new website, because there
is metadata associated with a paske.
The system can intervene.
And before you even start typing on thekeyboard 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.

(27:46):
You simply pick the one you wantto use, click on it, touch your
fingerprint, and you're assigned it.
So the discoverability, because wehave this method that associated
this PAs, is another reason why.
They're just purely , better than, , thetraditional method , of using or passives.
Yeah.
One other

Tim (28:02):
detail.
Cause I think it's important thinkingabout , the history and , the U two
F, even some of these older protocols.
The other thing that's stored with thecredential is, let's call the relying
party id, ? Which is all of these PAs keysare solely bound to single site, ? , a
pasky created for login.microsoft.comcan't be used against accounts.google.com,
? And that's just one of the core securityand privacy features , of this technology.

(28:23):
And that's existed pre pasky thatexisted with normal FI oh two
credentials that existed with Utwo F, all these things, right?
They're called Origin boundcredentials, which is one of the
most important things about them.
So , , if I go to amazon.com, I amnever gonna see a list of credentials
for google.com in that list.
it's, prohibited by the specs themselves,

. David (28:40):
So you're mitigating the possibility of cascade to zero, hopefully.

Tim (28:45):
Yep, exactly.

Mishaal (28:46):
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 aPAs key, what's stored on the device
is a private key, and that's uniqueto that device, but it can be backed
up to a cloud service provider suchas like Google Password Manager.
, is there going to be some way to transferthose pro out from say Google password

(29:07):
manager to other password managers?
If you wanna switch to last pass

Tim (29:10):
or something.

Christiaan (29:12):
I mean, I thoroughly hope so.
, I think that is the intent isthat 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 theuser specific platforms.
The problem is hard though, ? We'vealready said that we wanted
to do better than passwords.
Today with password managers, you canexport your passwords to plain text.
they're, , they're strings anyway, right?
It's fairly easy.

(29:32):
It's not that great if an attacker wereto get hold of your list of passwords,
but because websites claim , and acton passwords as if they're inherently
insecure anyway, there is normallyadditional layers of authentication.
There might be mfa, there mightbe other stuff on top of that,
?With PAs.
We're hoping that that is yoursecure credential that you use and
that there wouldn't be additionalstep up needed in the normal sense

(29:55):
when you log in with a paske.
If we therefore allowed users tovery easily just export these things
to a file on a disc, that would bethe exact way that attackers would
now try to , get hold of these andessentially compromise the system.
So it is a little tricky for us to figureout exactly how we architect the solution.
, I don't know if exporting to a fileon this is the right solution, even

(30:17):
encrypting that file with a password, . Ithink users could be tricked or do into
doing that, revealing that or uploadingthat file somewhere, which would counter
or go against all the security guaranteesthat Paske are supposed to provide.
So I totally agree with thissentiment and I think that's
absolutely something that we want tosupport how we do that in practice.
I think we're still a little bit unclear.

(30:38):
I know, Tim, if you have anyadditional like, insights on that one.

Tim (30:40):
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, , andMichelle, I know we talked about
this completely casually one day.
This all also ties into a lot of theidentity 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

(31:00):
authentication, ? So we are alsothinking about this in the context.
, could we come up with a universalcredential transfer type format, ? Where
it can move your pass keys, it can moveyour verifiable credentials, it can move
maybe even your mobile driver's license.
That's a very politicaltopic, so it won't go there.
But like those types of credentialsbetween platforms and ecosystems and
wallets , is a password manager just nowgonna become , a wallet, it kind of was

(31:22):
the original digital wallet in many ways.
Sure there were just , beardata in their bear credentials.
But, , we expect password managersto evolve into pasky managers and
all these things, so we really wannathink about it holistically as well.
And we certainly didn't wannarush into a solution that dumps
a text file out . So, top of mindthe feedback was loud and clear.
, we knew it was coming and we justwanna make sure we can do it the.

(31:43):
Great.

Mishaal (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 thingsthat's top in mind for people who
are interested in paske or wonderinghow paske replace passwords.
With passwords you have the password,with you, you can use it on any
device that you have access to theinternet or sign into those apps.
Whereas with past keys you have theprivate key that's stored on the device

(32:05):
and say, the typical example is you havean Android phone and a Windows pc and you
created an account on your Android phone.
Private keys on your Android phonebacked up to Google Password Manager.
But your Windows PC is, windowsOS with Microsoft Manager.
And so , how exactly would you use yourcredential, sort on your Android phone
to sign into a website that's, on yourWindows pc and how exactly does that

Tim (32:28):
process.
Absolutely.
Yep.
, so, one of the biggest misconceptions,which I wanna start with is that
, the PA key itself, as Christianmentioned, the private key and
the MEDA moves across devices.
That is not what happens assignedassertion moves, , just like , if you're
familiar with , some of the federatedlogin 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.

(32:49):
It's a lot more complicated, obviously.
But this is another great example ofsomething that's implemented in the
c a layer, which is not somethinga website needs to worry about.
So, , The pattern we'd like to evangelizewith it is that users are not using their
phone to sign into something on theirdesktop 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.

(33:10):
Windows will be a little bit furtherbehind just different dev cycles.
It's a old operating system.
So obviously I may have PAs keyson my phone that I don't yet,
have a PAs key yet in Windows.
So when the day comes, when Windowshas 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 relyingparty, you would see that, that.

(33:32):
Credential came in from another device,there's actually some metadata that let
you see it, and you pop up somethingthat says, Hey, do you wanna actually
enroll Windows or this device so thatyou don't need your phone every time?
And then at that point you havea, a PASKY that's syncing in
the Microsoft ecosystem and inthe, let's say Google ecosystem.
And then you never need your phone tosign into that service on Windows again.
Right?
? So we, hope that's the pattern.
That's what a lot of the developerdocs on PAs, keys dot, Dave will

(33:55):
evangelize because , we don't thinkit's a great experience that the user
has to take their phone out every time.
There's nothing stopping themfrom doing that if they want.
But , it's not an ideal experience.
And so, the way it actuallyworks, , there's been a heavy,
heavy focus on QR code basedauthentication, ? That's what it is.
And it's really not.
The only thing that QR code doesis allow the devices to link.
And we're explicitly saying,linking, not pairing, because
it's not like a Bluetooth pair,

(34:15):
?There is though actual Bluetooth layer persistent relationship
between these devices.
What's happening is when you, scanthe 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, ? Andso, using Bluetooth low energy

(34:35):
beacons, , which have a very short, it's.
Bluetooth Classic, where itgoes into , another apartment.
It's a much shorter range.
We can actually prove that the phoneis nearby to , the client, which would
be the desktop in this case whichhelps check the box of proximity.
And what essentially happens isthere's every authenticator, so let's
call the phone the authenticator.
They have a cloud service thatactually is, think of it as a big
router that can actually help therequest get to the phone and back,

(34:59):
?, it's to like a web socket model, ? And so when you scan the QR code there's
some information that's shared inBluetooth advertisements, ble the
advertisements between the devices.
Obviously they have to be closeto each other to see that.
And then both parties canactually go establish a secure
connection to this service.
And then at that point, the same exchangethat happens to a USB security key or n.

(35:19):
Happens just over that transport.
So the official protocol levelname for this is called hybrid.
Not very exciting.
But the way we refer to itmore 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 codesnow, and the nice thing is too, is

(35:40):
actually on Android specifically youdon't have to do the QR code step
every time after you've done it once.
As long as you leave the remember mecheckbox on your phone side, you'll just
click on your phone in the notification.
So I'm curious,

David (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 theirsmartphone, which desktop, PC doesn't
have a camera, it doesn't have Bluetooth.
, are there fallback

Christiaan (36:03):
methods.
Yeah, that's, a good question.
, I think , there's two things.
The first thing, I'll quickly justgo back to what Tim said, because I
think it also feeds into this answera little bit, is early on we spoke
about PAs keys and how they getsynced using Google Password Manager.
I think there's one importantthing we have to call out.
Passwords in the Google Password Managerare synced to wherever your Google
password manager was, ? You could evenhave it on iOS, you could have it on

(36:24):
Windows, ? You have it on Android.
PAKEs are fundamentally differentbecause 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 gonnabecome available to Chrome on Windows.

(36:45):
The only way to use it is usingthis cross device mechanism
that Tim was referring to.
The same with iOS.
You can have your Google passwordmanager on iOS all day long.
Your PAs keys are notgonna be there right now.
You have to use your Android phonein order to scan a Q code on your
iPhone, which will then provide , thislocal mechanism , for transferring the
signature over to sign the user in.

(37:06):
Reasons for that is mostly security.
There's also another reason there,in terms of app consistency on.
, iOS Chrome and Safari and your appsrunning on iOS all use the exact
same PAs out of the exact same store.
So users don't have to worry thatChrome is storing Paske over here.
Facebook is storing Paske over there.
Safari is storing PAs keys over there.

(37:26):
No, no, no.
They're all stored to theiCloud key chain today.
, so consistency at the platformlevel was very, very important to
us when we devised the system.
So just one thing I wanted to callout, back to David's question, which is
like, okay, now that there's even morediscrepancy here, like a user goes to
an old Windows device, doesn't matterif they're using Chrome, they're not
gonna have their PA keys there, right?
Their past keys is on their Android phone.

(37:47):
How do they use them?
, the main issue here is that proximity iscritical to the security of the solution.
If we don't have that localproximity check that we have through
Bluetooth, it technically meansagain, that a user can be duped.
Being fished essentially,
some person, somewhere in a differentcountry could go try to get the user to go

(38:07):
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 lookingat, 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 doingthe proximity today it was a
lowest common denomin ? It'savailable in lots of places.

(38:29):
It's fairly robust.
It works across, devices.
We are looking into otheralternatives there as well.
Things that we mightwanna do in the future.
This one is not gonnahelp for David's question.
UWB, for example, ultra wipa,even better, in range and stuff.
But again, that's technologythat'll come out in the future.
Depending on how many users are in thisboat, where they have older systems

(38:49):
that they need to sign in, one mightthink of other types of local transports
which we could use to prove proximity.
There are many technologies available tous, like local network access is one that
some applications use to gauge whether,users , are physically co-located.
That's not something in the protocolright now, but it might be something
that we wanna look at in the future.
Today we're.

(39:10):
Users are gonna have to livewith one leg in either ecosystem.
One leg, probably still in passwords fora while on these older legacy devices.
One leg with PAs keys.
The benefit of this is to the relyingparty of the services implementing it.
The less the user is subjected topasswords, the more scrutiny can we
subject them to when they do needto log into that legacy system.

(39:31):
Today we have to allow passwordsthrough as a first class method
because that's all we've got.
We can actually start to demotepasswords to actually, you wanna use
a password, maybe you can't log inimmediately, like maybe we subject
your account to in one hour hold.
Or while we lost verifications toall your other logging devices.
There's lots of things that we coulddo if passwords weren't to be treated
as like a first loss login primitive.

(39:52):
But we don't have a straightanswer today for legacy devices.
I think passwords plus some additionalscrutiny is probably what we're
gonna have to do there , for a while.

Tim (40:03):
Yeah, I think realistically in the short term, and let's say.
Two to five years.
, the goal is to de-emphasizepasswords, ? Start removing them solely.
A user that has, let's say three passkeys , may be treated differently from
a sign and flow than a user who has onepass key and a password in sms ? The
capabilities are there to have veryrich, dynamic experiences that can change

(40:23):
over time , as these levels change,
?Of, of users with pass keys and penetration and all that.
So it's really about de-emphasizing , asChristian mentioned, like you come
in, you've used a pass key for ayear now three different pass keys
from 3D devices, and all of a suddenyou 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 (40:42):
And just to be clear, existing accounts that would've been
created with username, password, thosecan be migrated to used pass keys.
Is that right?

Tim (40:51):
It's not automated, right?
, if you actually see this onPayPal, I believe they're the most
widely known deployment right now.
If you sign into your PayPal accountwith user and password, they're
probably gonna do an SMS check.
And then if you're on a platform they'resupporting, which I believe right now
is,, iOS, that's their first rollout.
They will actually pop an interstitialthat says, Hey, upgrade to a pasky.
? So , the user still has to do something.

(41:12):
The relying party has to do something.
We get asked a lot, can wejust , bulk enroll a bunch of PAs?
I think there are some things wecan do to make that easier, which I
think , we're starting to look at.
But , it's unfortunately not likejust this, flip a button and they go.
But you know, in theory it's aone time thing for each account.
So, Another

Mishaal (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 keysbeing used for authentication?
Cause I know when you're.
Using your phone, you can dobiome authentication or a pin to
say, I want to use this past key.
And where will we see securitykeys being used in that process?
I

Christiaan (41:46):
mean, , I think a unique perspective on this because that's the
question that we have to ask for Googleaccounts today, ? We have lots of users
using security keys on Google accounts.
We are fully , marching aheadin 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 , aswe're moving on, web and platform

(42:08):
credentials and toskey that we didn'twanna leave security keys behind and
treat them as second class citizens.
So today, when a website, when arelying party or developer supports
PAs keys, they have to go out of theirway to not support physical security
keys, ? The way that I think about thisis if you have a five two compatible
security key, that five two compatiblesecurity key can store PAs keys,

(42:30):
?They might only be on that single device.
They're not synced to a cloud orsomething like you might have with your
phone, ? But your PAs key now lives onyour physical security, and you should
be able to use that exactly the sameway that you use your phone now on the
phone, you authenticate by touchingyour fingerprint or typing a pin.
On a 5 0 2 security key.
I mean, I have some security keys withfingerprint readers on them, right?

(42:51):
That's stuff that exists.
If you don't have one of those mostof 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 forall the websites for which you have
PAs keys on that security key, right?
, so to go to Google and register a fightertwo security key, or to go to Google and

(43:12):
register a, physical phone in the futureas a paske should be exactly the same.
And for users who think that they'rebetter served by having the physical
security key, Maybe it's becausethey're afraid they might lose their
phone, they wanna have a backup.
Maybe it's because it's a, specifictype of high risk user who's worried
about, having PAs keys on phones andthey prefer having a security impact.

(43:33):
We're essentially opening security supportup to much, much, much wider array of
websites through the PAs key initiatives.
Because websites who used to look atthis 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 keysupport almost for free, which I think
is , a very nice side effect of theway , the protocols been architected.

Tim (43:57):
Yeah.
And , ? We plan at least onthe window side, a phone and a
security key will always have equalfooting, ? , any remote device will
show up , on the windows, hello screen.
Security key will still be there.
We're not planning ondeemphasizing it at all.
We have in the enterprise space, and Ihate the word enterprise, but like , the
more work centric things we expectsecurity key usage to actually increase.
And so that will remain , anoption as it is today.

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

Tim (44:27):
Yeah.
So actually, as part of this initiative,one of the things that I think we.
I shouldn't say fail becauseeverything's a learning process,
but , in this particular iteration ofthis technology I think we, were able
to come together and have developerresources available pretty quickly,
?Comprehensive ones, right?
there's a lot of resourcesthat happened over the years.
With Web off and other things, butthere's 10 different sites to go to.
And they all do differentlevels of detail and they don't

(44:47):
necessarily pull together a story.
So that's where Pass keys.dev came from.
That's a collaborative effortbetween 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, ? Wewant keep it as open as possible.
It's more or less governed through.
A group called the W3CCommunity Adoption Group.
If you are a developer and you havedeveloper feedback on pakis.dev under

(45:10):
about, there's links out to that group,you can join that free of charge.
And that's where , we take in feedback andrelay it to , the actual working groups
and even the platforms and other things.
So I would highly recommend youbookmark pakis.dev at a minimum.
It's got a great device support matrixthat , we literally update every week
with this new and flag is supported.
So, shameless shameless bragthough, something I worked on,
but was super happy with it.

(45:30):
And , we've gotten a lotof great engagement on it.
On Twitter.
I don't know if I hate saying thatanymore, but I'm Tim Capal on Twitter.
I still use both.
And then on Macon what is my thing?
It's like a whole TimKali InfoSec exchange.
So we could probably put that,it's actually on my Twitter.
It's probably theeasiest place to find it.
. Christiaan: And then , from our side, I think, VAs a great resource here.

(45:52):
We also have.
Some documentation overon the Android side.
I do realize that it's not complete yet.
, at this point we are working onthat actively, but if you go to
developers.google.com/identity/paskeys you can find our documentation
and we'll be updating that.
As more functionalitygets pushed out there.
There is a whole lot of things happeningon Android with PAs over the next year.

(46:15):
We've already publicly indicatedthat 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 pakisthings, that be, coming out early
23, towards the middle of 2023.
So lots of activity andeverything essentially will be
published on that, developers ofgoogle.com/identity/pakes website.

(46:38):
And then of course, on, onTwitter, I haven't figured out
how to make Master on Work.
I tried an instance that neversent me the email to set up
my password, so not there yet.
But on Twitter, you can follow meat Christian with two as brand.
So if you're interested, usuallyif something happens on the Android
or on the Google side, I tweetabout that pretty, pretty quickly.
So if you're interested in anythinghappening on Android or Google with

(46:58):
Pakis, feel free to gimme a follow on.

David (47:01):
And thank you both for joining us.
There isn't a great Esper plug because wedon't really do anything with past keys,
but this has been immensely fascinating.
The evolution of the password.
I mean, obviously we allknow that passwords are bad.
I think either for the right reasons orwrong reasons, everybody hates passwords.
So I'm actually curious about onething, and this is a bit of Android

(47:21):
esoterica Christian maybe, you know,but Tim maybe you know as well.
So when it comes to two-factorauthentication, everybody's got a little
bit of their spin they like to put on it.
I've always found Google's tobe not unique, but it's the
only time I've seen it used.
Google

Tim (47:37):
uses a two digit

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

Christiaan (47:50):
that, that's a great question..
Well, I mean so much tosay about that, right?
So, I think in general, sick digitconfirmation codes is necessary when
you have a one way communicationarchitecture, 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 thephone you type it back into Google, but

(48:11):
I mean, you're not replying back on thechannel that you got the code from, right?
So in order to prove to Google thatyou got the right code, six digit
codes is usually the standard forthat, which is also the same standard.
We ended up using mostly Fort OTPcodes generated by applications, ? So
you have like an app like Google orsomething that generates TTP codes.
Usually six digits is from anentry perspective, that was good

(48:31):
enough so that we can say, well, ifsomeone entered that code, chances of
someone just like randomly guessingyour code, probably pretty slip,
?So six digit is where we had it.
Then we moved away from that and we movedto push based authentication systems
where we sent a message to your phone.
You reply on the phone directlyby saying, yeah, it's me.
Technically no code is needed there.
? When you say yes on that particulardevice, , you can go cryptographically

(48:55):
from that device back to Googleand 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 appendany length code essentially that you want.
There might be a cryptographicsignature that the companies that, so
there is no need in that particularexample for showing any codes.
Apple is interesting intheir implementation.

(49:15):
They would do the push, butthen they would also still show
a code that you have to enter.
I mean, from our perspective, , that'snot really, super required.
And in most cases, when you loginto Google, the yes on your
phone is all you have to do.
However, in certain cases whenlogging into Google depending on leg
schedules and other things, we mightalso in addition, show you these
two digit numbers and have three ofthem that you have to pick through.

(49:37):
The philosophy behind that isessentially saying that it's the same
as this Bluetooth bearing thing, ? Ifyou'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 thatyou 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 Googleside, we wanna be sure that you
are logging into the right device.

(49:59):
You're not accidentally loggingin some one other's device that
also just happened to, at the sametime, initiate the logging request,
having your username and password.
And when you say yes, you're actuallyapproving their device and not your own.
They would technically have adifferent code on their device,
a different two digit code thatwe displayed on your phone.
So this matching here is to weed out,an attacker that just happened to, at

(50:23):
the same point in time, maybe they'resitting next to you in startup, they're
watching you log in, and then theydid enter exactly at the same point
that during enter, when you approveon your phone, who knows which user
device you're actually gonna approve.
Now it's not foolproof, ? Thereare still ways to get beyond that.
If you're a sophisticated attacker witha man in the middle, you can probably
defeat some of these things as well.
But at least it tries to weedout 99% of those types of timing

(50:45):
attacks, where these codes wouldthen allow only the right device to
be logging and not the wrong device.
So, a little bit of a long windedanswer, but there is method in the
madness here, but in most cases,users wouldn't even see those.

Tim (50:57):
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 typein the number because the number of
users that were correctly selectinga random number because it popped
up, was insanely high, right?
The probability is still pretty good.
So we actually have the optionnow, admins can turn on.
You actually have totype the number for us.

(51:18):
Microsoft employees we haveto type in the actual number.
You can't just select it . Soit, funny to watch the
progression , of that experience.
We call it number.
That's,

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

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

David (51:43):
there was a good story there and it was a good story.
Thanks for sharing, Christian, becauseI don't think many Android users would
have any idea why that system exists.
So hopefully they learned somethingand hopefully they learned a lot today.
Talking about paske.
If you're not interested in personalsecurity credentials or credentials
otherwise, but securing devicesspecifically, come talk to us at Esper.

(52:04):
We do Android device managementbetter 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.

All Episodes

Episode Transcript

Popular Podcasts

Stuff You Should Know

Dateline NBC

On Purpose with Jay Shetty

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}What is a passkey and why should you care?

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}Stuff You Should Know

Dateline NBC

On Purpose with Jay Shetty

All Episodes

What is a passkey and why should you care?

Stuff You Should Know