What is a passkey?
Hi, everyone. Leo Notenboom here for
Askleo.com.
In the coming months, you're going to start hearing something about passkeys.
I want to describe exactly what they are at a conceptual level,
how they're different from passwords and passphrases, and why.
Honestly, I'm really excited about seeing them deployed and being used.
Okay, so password, passphrase, pass key.
What's the difference?
Well, a password is a traditional word.
Now, we don't necessarily recommend you use actual words as your password.
In fact, the ideal password is a string of random characters,
but it's usually a single thing, somewhere between eight, 12, 16,
20 characters or more that act as your authentication, your ability to provide
your password, prove that you are who you say you are.
A past phrase is basically a longer password but made up of multiple words.
The canonical example that we've used for years is correct horse battery staple.
Those are four random words.
There's a conceptual way of thinking about them that makes them easier to remember.
But it's a very long,
easy to remember password that you can then use in place
of a regular password for services that support long pass phrases.
Of course, don't use correct horse battery staple because everybody knows it.
Make up your own.
A pass key, on the other hand, is something entirely different.
It has nothing to do with anything you need to type or remember.
And honestly, that's pretty cool.
Now, I do want to preface all this by saying this is a conceptual overview.
It's based on what I understand pass keys to be right now.
As it turns out, getting the details of exactly how
passkeys are implemented has proven to be a little bit difficult.
But fortunately, you don't need to know those details.
The conceptual high level overview will help you understand what they are,
why they're safe, and how you'll end up using them in the future.
Passkeys are based on cryptography, specifically public key cryptography.
Now, we'll talk about the public part in a moment, but the fundamental concept
behind this cryptography is that it's called Asymetric Cryptography.
Semetric cryptography is what you're already used to.
That's where you have a password that you use to encrypt something,
and then you use that same password later when you want to decrypt it.
Asymetric cryptography uses two separate keys.
Basically, there are two large numbers.
They are generated together and they have
a very special and interesting relationship.
And that is simply this.
Call them A and B.
Anything you encrypt using A can only be decrypted by B.
Similarly, anything encrypted using B can only be decrypted using A.
In fact, if you encrypt something with A, you can't even use A to decrypt it.
You can only use B.
So they are asymmetrical.
You use one to encrypt and you decrypt with the other.
Great. It's wonderful.
I find it absolutely fascinating
mathematical magic, but that's fundamentally what it is.
It's so much magic.
Now, I've talked about public key cryptography.
The fact that these two keys, A and B,
have this weird relationship means you can do something really, really interesting.
I can make one of them public.
I could just give it to you.
So if I keep my A secret and I make
the B key public, two things can happen.
One, somebody can use the B key, which is freely available,
to encrypt something that then only I can decrypt because I have the matching A key.
That A key is kept secret.
It's a private key.
That's why it's called private and only I have it.
Anybody can encrypt something using the B
key because it's public, but only I can decrypt it.
This is a very useful and fundamental
technique to sharing encrypted documents with specific individuals.
Now, the other interesting thing you could
do with this is I can encrypt something using my A key,
and anybody can decrypt it using the B key.
So what's the point?
The point is, if that decryption using
the B key is successful, that proves
that only I could have encrypted it because only I have the A key that would
encrypt it in such a way that the B key would work.
Anybody can encrypt something using a public key such that only one specific
person with the private key can decrypt it,
and anybody with a private key can encrypt something so that that B key can be used
to prove that they are the ones that encrypted it in the first place.
Okay, great.
Now we've got this public private key pair thing going on.
Let's go ahead ow do we use it for authentication?
Well, you end up creating, again, these key pairs.
We have a key pair A and B.
Let's say you want to use it to log in or sign into a server.
What you end up doing is you give one
of those keys, we'll call it the public key,
you give one of those keys to the server administrator,
and they put it in a special place associated with your username.
So they store username and public key.
Now you come along and you try to sign into that server.
The server basically says, in effect, okay, I'm thinking of a number.
I'm going to encrypt the number that I'm
thinking of using what you claim to be your public key.
Now I'm going to send you that encrypted BLOB.
Tell me what number I was thinking of.
Because they used the public key that was associated with my account,
only I can decrypt that data, and therefore my ability to successfully
decrypt that data and then tell the server what number it was thinking of says,
You must be You, I must be Me, and therefore I'm authenticated.
This technology that I'm describing is actually quite old.
I've literally been doing exactly what I've just described for something like 20
years as I connect to my Linux servers, of which askleo.com
happens to be hosted on.
It's wonderful because I never have to type in a password.
It's the possession,
the fact that I have the secret key in my possession that proves I am who I am.
The server holding the corresponding public key can then use that relationship
to confirm I am who I am when I try to sign in.
Great.
Pass keys.
Now, let's finally talk about pass keys.
Pass keys are essentially exactly what
I've just described with one very important difference.
I started the public key authentication
description by saying we create a key pair.
Passkeys actually do all that automatically for you in the background.
So they do set up a public private key pair.
The public key is kept on the server, say Google.
The private key is kept on your machine.
And I'll talk about how that's done securely in a moment.
But when the time comes for you to sign
in, then Google does the same thing that I just described.
Again, conceptually, Google says, Hey, I'm thinking of a number.
I'm going to encrypt it with your public key.
If you can successfully decrypt it,
you must be holding the corresponding private key and therefore you must be you.
It really is that simple.
Now, one of the things that is a little
interesting is that passkeys are unique to each device and to each account.
So for example, when I sign into Google,
I might have a passkey set up for my Google account on my desktop machine.
I might have a different passkey set up for my Google account on my laptop.
I might have a different passkey for my Google account on my Android phone.
I might have a different passkey for my PayPal account on my desktop
and my PayPal account on my laptop, and so on, and so on.
Yeah, there's a lot of passkeys.
The good news here is that it's all transparent.
It's all handled behind the scenes.
It's nothing you will need to keep track of.
So how does it get set up in the first place?
If I'm not keeping track of it,
how is it getting set up and how is it getting set up securely?
There's a few scenarios that we want to walk through.
First off, let's say you're creating
a brand new account, a brand new Google account,
and you're only going to use passkeys for authentication.
You connect up, you create your account.
By definition, you are you.
You are the person creating the account.
Therefore, Google can, right then and there,
create a key pair and store the private key on your machine.
Because like I said, you are you.
Now, when you come back later to sign in, the key pair is there.
You are you and you don't have to do a thing.
Now, if you're adding passkeys
to an existing account, as I recently did with my Google account,
then you would sign in to that account some other way first.
So for example, in the case of my Google account, I would sign in using my password
and my two factor authentication, and then I would instruct Google to say,
Okay, let's set up pass keys for this account.
It does so.
The key pair gets generated.
The private key is stored on my machine,
and now I can use pass keys for that account on that machine moving forward.
Now, what if you have an account
set up to use Pass Key authentication, maybe only Pass Key authentication like
in our first scenario, but you want to now use that account on another device?
Well, you go to that device and you try to sign in.
You then will have a number of different
options depending on the service that you're using this with.
You may be able to sign in some other way using a password,
which at that point would set up the key pair.
But I said that this account is passkey only.
Well, you may need to then confirm your sign in
on another device that is already authenticated.
So for example,
if I'm signing in on my phone for the first time,
I may get a prompt on my desktop that says, Hey, is that you?
If you then say, Yep, that's me,
boom, the phone gets a key pair of its own generated at that point.
Or you would confirm your sign in using
some other technique like clicking on a link in an email that is sent to you
or an SMS text message that is sent to you that is based on the email address or
phone number already associated with your account.
But once you've gone through this
bootstrapping process of securely identifying yourself on the new device,
then the key pair can get set up on that device and you're good to go.
A lot of this seems almost too good to be
true because there's a lot you don't have to do.
All of this is happening behind the scenes.
How can this possibly be secure?
There are two parts to it, and in fact,
the two parts contribute to it being honestly more secure than passwords.
The first one is simply that, let's say there's a data breach.
Let's say that the service you're using
with passkey only authentication suffers some a breach.
What are the hackers going to walk away with?
They may walk away with your name, your email address, your username,
that stuff, but there's no password for them to get.
The only thing they can get is this public key.
But the public key is public.
We don't care who has it because there's nothing they can do with it
that would cause us to do something to try and authenticate using our private key.
We're only going to use that private key
when we authenticate with the real service.
Great, the hackers have a public key.
Good luck with that.
There's nothing they can do with it.
There are no passwords to be stolen
if passkeys are the only authentication mechanism for the account.
Now, I've said that the private key
associated with the passkey is super important.
That's the thing that proves you are you.
Your possession of that private key is what proves you are you.
So that needs to be stored securely.
And it is.
In almost every case, the private key is stored using your
operating system's secure credential manager.
That manifests what that looks like is
when you try to sign in to an account and it tries to go through this pass key
authentication loop, you may be asked to authenticate yourself,
not with the service, but with the operating system.
So Windows might ask you for...
Theoretically, they could ask you for your Windows password.
Or more commonly, because it's that much
more easier for folks, is you may be asked for your login PIN if
you set one up, or your face ID, or your fingerprint.
After you've provided that level
of authentication to Windows, it then unlocks your credentials store,
grabs the private key that is then used as part of this Pass Key authentication.
You didn't have to do a thing other than
maybe touch a fingerprint sensor, or have a face, or enter your PIN.
But that's it.
There was nothing for you to remember outside of your Windows login.
So the bottom line here is that Pass Keys honestly are really exciting.
I'm really looking forward to seeing them deployed more and more.
Don't get ahead of yourself.
It's going to take a while.
There are services that are currently implementing Passkeys.
Google happens to be one of them.
But it also requires operating system support and I believe browser support.
It's going to take some time,
especially for the other accounts that you might be using online.
They're not all going to switch to using Passkeys right away.
There's going to be a fairly lengthy transition.
But my recommendation is that now that you
understand conceptually why passkeys are more secure than just passwords that you
might lose, consider as they show up, switching to passkeys when available.
There's actually a really good chance
that it could all happen automatically without your even realizing it.
Because the operating system,
because the services, as they implement passkeys,
don't necessarily need to make it an option.
They could just start doing it.
And what you would notice is that over time, you might be entering your password
for that service less often and supplying your fingerprint or your
face or your pin to Windows a little more often.
Anyway, I find it really exciting.
I'm looking forward to seeing it implemented.
I hope this helps you understand a little
bit of what passkeys are going to be about.
For updates, for comments,
for links related to this article and more, visit
askleo.com/157308. I'm Leo Notenboom and this is
Askleo.com. Thanks for watching.