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.
