A more secure, more convenient alternative to passwords.
Everyone knows the frustrations of creating, using, managing, and forgetting passwords. But what if there was a way that once you signed in to your device, all the subsequent signing in happened securely and automatically without your needing to remember — or even enter — a thing?
In the coming months, you’re likely to hear more and more about passkeys.
Not passwords. Not passphrases. Passkeys.
You might already be using them without realizing it.
Become a Patron of Ask Leo! and go ad-free!
Passkeys
Passkeys use cryptography instead of passwords to authenticate your identity and allow you access to an account. Passkeys are more convenient and more secure than traditional passwords. There’s nothing to remember and nothing for a hacker to steal.
Pass what now?
Let’s differentiate between these three authentication methods: passwords, passphrases, and passkeys.
As the name implies, passwords at their simplest are an authentication method where, in addition to your user ID, you prove you are you by entering a “word” — a collection of characters you previously defined as the password — to your account. As examples: “password” is a very bad password because it’s short, simple, and easy to guess, but “jy9zdQbNsWQmuyciC2xw” is a pretty good one because it’s long, random, and basically unguessable.
Passphrases are, again, as the name implies, passwords made up of multiple words. “I Love Lucy” is a bad passphrase because it’s a famous phrase all on its own. Until it was used as a popular example of a passphrase, “Correct Horse Battery Staple” was a good passphrase because it’s lengthy and the words are unrelated. “John Snow You know nothing” is a decent passphrase because it’s an erroneous1 mix-up of an easy-to-remember phrase.
Passkeys are something else entirely. They use what’s called public key cryptography. They might be the safest and easiest to use but the most difficult to explain, so bear with me.
Important
This is a high-level conceptual overview, not meant to be accurate at a detailed level. Actual passkey implementation details are difficult to get. I believe the concepts here to be accurate enough to understand the basics of how the technology works. If I later discover inaccuracies in my assumptions, I’ll update the article, of course.
Key pairs
Public-key cryptography is the workhorse of most online encryption. It’s what’s used, for example, to secure https connections, the “SSL/TLS” connections configured in your email program, and much, much more.
The concept is simple.
Two large numbers, A and B, are created using a special mathematical formula. Among many other things, they have the following relationship to one another:
- You cannot calculate one from the other.
- Anything you encrypt using one can only be decrypted using the other.
That last point is very important. If you encrypt some data using the number A as the encryption key, then only B can be used to decrypt it. Similarly, anything encrypted using B as the encryption key can only be decrypted by A.
A cannot decrypt A, and B cannot decrypt B. Only B can decrypt something encrypted using A, and only A can be used to decrypt something encrypted using B.
Think of it as two locks, A and B, both on the same box.
If you lock the box using key A, it can only be opened using key B.
If you lock the box using key B, it can only be opened using key A.
It’s digital and mathematical magic, as far as I’m concerned. Beautiful magic, at that.
Public and private
I did mention this is typically called “public key” cryptography. Here’s why.
“Public key” encryption or authentication refers to the use of both keys in these magical key pairs. One of the two is referred to as the “public key” and the other the “secret” or “private” key.
If I keep A secret and make B public, then two really interesting things are possible.
- Anyone can encrypt something using the public key B that only I can decrypt using my secret, private key A.
- If I encrypt something using my private, secret key A, anyone can confirm that only I could have encrypted it if they’re able to decrypt it using the public key B.
Indeed, I have a publicly available public key that anyone can use to encrypt a message to me. Given that only I have the corresponding private key, only I can decrypt it.
Public key authentication
Before we can get to how passkeys work, we have to understand public key authentication. Public key encryption can be used to enable authentication that doesn’t use passwords (something that’s been used on Linux systems for decades).
First, you use a tool to create a key pair (two really large numbers, remember): a public key and a private key.
You keep the private key safe and secure, and you don’t share it with anyone.
You give the public key to the owner of the server you want to connect to.
Now you try to sign in to the server.
The server says, in effect,2 “I’m thinking of a number. I’ll encrypt this number using your public key and give you the encrypted result. Now tell me what number I’m thinking of.”
Since you are in possession of the corresponding private key (which you kept safe and secure), the tool you’re using to sign in can use it to decrypt the encrypted data the server sent you. It can then respond to the server, “No problem, the number is…” and provide whatever the number is.
Because you had the matching private key, only you could have decrypted the information, and only you could have responded with the correct number.
You must be you. And it all happened behind the scenes without you doing a thing.
I’ve been using this type of authentication to connect to my Linux servers for nearly two decades.
Passkeys and public key authentication
Passkeys are public/private key pairs that are automatically generated for you. The public key is kept on the service that supports passkeys — like Google — and the private key is stored securely on your computer.
When you sign in, the service responds with a challenge of some sort that is encrypted using your public key. Because your computer has your private key, it can correctly decrypt that challenge, proving that you are who you say you are.
Access granted.
And all of that is completely transparent to you, other than perhaps needing to unlock your computer’s securely stored repository of private keys. We’ll talk about that below.
Passkeys are unique to each device
Note that in its basic form, the passkey keypair is different for each machine you use. So, for example, I might have:
- A keypair for my Google account accessed from my desktop.
- A keypair for my Google account accessed from my laptop.
- A keypair for my Google account accessed from my phone.
- A keypair for my PayPal account accessed from my desktop.
- A keypair for my PayPal account accessed from my laptop.
- and so on…
Once again, all of this is managed behind the scenes for you; it’s nothing you need to keep track of yourself. The service keeps track of all the public keys associated with your account, and each device holds the private keys for the accounts that have been set up on that device.3
Passkey setup
How passkeys are set up depends on when and where you’re doing it. Let’s look at three possibilities: creating a new account from scratch, adding passkeys to an existing account, and signing in to an account using passkeys on a new device.
- If you’re creating an account from scratch using only passkeys for authentication, the setup process will create the key pair used for that service. The service will keep a copy of the public key, and the private key is securely stored only on your machine. You’re signed in on that machine automatically as needed.
- If you’re adding passkeys to an existing account, first you sign in to the account normally, proving you are you in the usual way, like a password. Then the process creates a keypair to use for that service and stores the private key on your machine. You’re signed in from that machine automatically as needed thereafter.
- If you have passkeys set up for an account but are signing into that account for the first time from a new device, one of a few things can happen.
- You’ll need to sign in some other way, perhaps using a password.
- You’ll confirm your sign-in by acknowledging a prompt on a different device where you’re already signed in.
- You’ll confirm your sign-in by clicking on a link or entering a code sent to the email address of record for that account.
You may already have encountered one or more of these. If, for example, you’ve signed in to Google on your PC and been instructed to confirm the sign-in on your mobile device, that’s probably a passkey at work.
The process will again create a keypair to use for that service and store the private key on this new device. You’re signed in on that device automatically as needed thereafter.
Passkey security
If someone gets your public key in a data breach, it’s useless. There’s nothing they can do with it. It certainly does not allow them to access the account. Unlike password hashes commonly found in breaches, there’s nothing to hack, nothing to guess, and nothing to recover.
You could post your public key on a wall somewhere and be totally safe. It’s called “public” for a reason.
It’s your possession of the corresponding private key that allows you to confirm you are you. It’s an important bit of information, a secret that needs to be kept safe and secure. It is kept safe and secure in the credential storage mechanisms on your machine. These are typically locked by default, so when a passkey is needed, you first authenticate yourself with your device. That could mean confirming your sign-in password for the device (say your Windows password on a computer), but more commonly it uses fingerprint or facial recognition, a log-in PIN, or something else easier for you to provide — yet still something only you can provide.
Do this
Get ready for passkeys. It’ll take time — a lot of time (think years) — as more and more services add passkey support, but this does seem to be the direction authentication is headed. I know I’ll be enabling it whenever it’s offered as an option, as recently happened on Google.
The good news is that it’s entirely possible the transition will be largely transparent, as you simply start using passwords less often as passkeys are set up behind the scenes.
I try to demystify technology every week. Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.
Podcast audio
Related Video
Footnotes & References
1: The correct spelling in this context is “Jon”, I’m told.
2: Totally making this up, but it gets the concept across.
3: Password managers are getting into the game as well, and may act as the secure repository for your private keys, allowing them to be automatically synchronized across your devices if you so desire.
Leo:
This one had me doubting my ability to comprehend new concepts; however, I now believe this is actually a round-about description of 2FA. If so, I have to say, for anybody interested in security, I’ve used 2FA since you first described it, and I think it’s great. Thanks.
It’s similar to 2FA, but it is NOT 2FA. It’s closer to having a unique extremely secure password for every combination of site and machine, managed not by you, but by the site and machine.
But will you have control to NOT leave a passkey on a device. For instance, say I want to access my Google account on a public machine at the Library because it has the information I need to research or book list I want to look at or whatnot. I certainly do NOT want to leave a passkey on that device that someone can leverage to get back into my account. (I make sure to clean the cache and history on public PC browsers before surrendering the machine for just this reason as cookies and other login mechanisms can get saved.)
I would expect so.
“John Snow You know nothing” is probably a terrible password as many Game of Throne viewers may not know it’s Jon and not John. If I were to use a guessable phrase, I’d add some punctuation, numbers, and switch up the puncuation.
“j0hn&sn0w&Y0u&Kn0w&N0thing”
Even “correct)horse)battery)staple” is probably OK.
My own take is, NEVER use words tgat can be found in a dictionary, if you can possibly helo it. (There IS such a thing as a “dictionary attack.”)
Try:
“Dzhahn&Snoe&Yoo&Noe&Nuhtheeng!5263”
I have other recommendations, but that’s all I’ll say for now. :)
A dictionary attack won’t work on a string of words unless it’s a well known phrase. The entire phrase““Correct Horse Battery Staple” would have to be included word for word in the dictionary, or have an algorithm that tries out combinations of words for it to be cracked. If such an algorithm were implemented, it would still take centuries to crack.
There are many (MANY) more words than there are letters, so a dictionary attack — which by definition would mean all possible combinations of all possible words — is pragmatically not feasible. Hackers have more effective approaches to getting lower hanging fruit.
“If you’re adding passkeys to an existing account, first you sign in to the account normally, proving you are you in the usual way, like a password. ” Wouldn’t this defeat the purpose of passkeys if it’s possible to sign in using a password? I assume they require on a second factor such as a text message or email to be able to add a passkey for a new device.
It’s pragmatism. Remember, most systems use passwords today, so I actually don’t even know of a passkey-only situation. WHEN we get there, though, then it’ll be a “confirm on other device” or by email or sms or something similar.
What happens when you get a new machine (laptop)? How are the private keys loaded on to the new system? (The old system was damaged and can’t be booted.) Do you use the “old” system and log in with the “old” password system?
Leo, you wrote: “Indeed, I have a publicly available public key that anyone can use to encrypt a message to me.”
[The words, “public key” in the above text, are a hypertext link to Leo’s public key.]
Jeez, Leo! How long is that Public Key! And, for God’s sake… WHY?!? Yeek!
[N.B.: It’s utterly useless to anyone — myself, for instance — who doesn’t have some version of PGP installed.]
It’s to demonstrate that it’s perfectly safe to have it publically available.
PGP and/or GPG. And normal usage is not to copy it from a web page, but rather get it from a keyserver, which is all part of learning how to use GPG/PGP. (Which is also why this type of encryption, while extremely powerful, isn’t something the average person is really set up to actually use).
As Mark said, it’s a) an example of a public key, and b) an example that public keys can be public, and c) available should someone knowledgeable ever feel the need to use it.
I just counted. Leo’s passkey is 7,309 characters long. … Counted it twice to be sure.
Just kidding. I merely copied and pasted it into Word, and got the character count instantaneously.
I think it’s long enough to be considered virtually unhackable using today’s technology.
If you’re referring to my public key, that’s not a passkey. It’s a GPG/PGP key. Same concept, but different implementation and different usages.
How does this technique relate to the use of password “helpers”, such as 1Password?
1Password specifically is adding passkey support. What that means is that rather than each device having its own key for each service, each service will have a single key stored in 1Password and thus it’ll “just work” when you set up 1Password on another device.
Not all password managers are doing this, and thus they’ll not be involved in passkeys.
Hello! Yes, passkeys have been around for many years for computer professionals working with servers, etc. The encryption protocols have been pretty great… up to the recent entry of quantum computing. Quantum computers work with totally different processing principles (algorithms) and from what I’ve read in the literature, can “hack” a standard passkey in nanoseconds. So, these passkeys will be great for keeping your data and communications private and safe from your average hacker, but in the future as more governments and other institutions buy into quantum computing, and it begins to become more mainstream, a much more secure approach will have to be thought up to be “quantum proof”.
It’ll be a long, long time before quantum computing has an impact on the average consumer’s day-to-day security.
I know Passkeys are still early on in development so my question may be premature. I was just wondering where say on a Windows PC would the private keys be stored? Would it be somewhere in a folder under /appdata or somewhere else on the PC? Could the keys be viewed or are they “locked” & not viewable? How does an account server with a public key know where the private key is stored? If they leave it up to the PC, what resident app knows where to go to get the private key to pass to the server? Is it the browser that gets the private key & passes the results to the server? I’d like to know answers to most of these questions before I would become comfortable with passkeys.
Since Leo has been using them for a long time for his Linux server logins, I assume he would know most if not all the answers to the above questions.
On the Linux side they’re not passkeys, but they’re like passkeys in the internal (public key pair) implementation. I keep my private keys in secure locations on my machine that, indeed, are just a file and folder situation.
Windows has a “Credential Manager” (You can just search for and run it) that is already in place to store credentials securely. My assumption is that PassKeys will use this. It’s unclear where exactly the information is store. Knowing Windows that answer is probably not simple.
I have been confused about how this all works forever.
When you say, “The server says, in effect, “I’m thinking of a number. I’ll encrypt this number using your public key and give you the encrypted result. Now tell me what number I’m thinking of.” I don’t understand how this can possibly work. If the message sent to me is encrypted by the Public key, I don’t see how anything besides the Public key can decrypt it. I assume I only know the Private key, not the Public key. Help!!
Up earlier in the article I talked about this. Public and private keys are PAIRS with the following property:
– something encrypted by the public key can only be decrypted by the private key
– something encrypted by the private key can only be decrypted by the public key
It is, indeed, mathematical magic.
Leo,
Way too technical. Just tell me how it interfaces with me (Google for example) and how I use it. It’s great to know an outline of how they work technically but I still am not comfortable HOW to use it. And I AM USING IT for Google already but it seems to have “variants” and I’m not comfortable with USING IT yet….
I haven’t jumped on the passkey bandwagon just yet, but I will switch to using them as they become available. I already use a passkey (I think) with my Microsoft account and I will set up passkey authentication with google/gmail when the Microsoft Mail client works with them. Until then, I may sign into my google services using a passkey, but my Mail app will still use a traditional password. I have a fingerprint scanner on all my computers for easy login/authentication using Windows Hello in Windows. I’m eagerly awaiting reliable support for them in Fedora and Manjaro (the GNU/Linux distributions I use on my PCs). I suspect bio-metrics presents the best/safest option for authentication to access the local key store. Regarding quantum computing, it may be a while before we must concern ourselves with it, but that technology may offer an even more secure way to authenticate – quantum entangled pairs, where one half of the pair resides on my device, and the other resides in my account data on a server with which I have set up an account. I do not know anything about quantum entanglement, but the technology sounds like something worth investigating.
This has been a stream of consciousness from
Ernie
The gentleman above said it well, way above my comprehension.I have a Google Titan physical key, is that the same thing?
No. That’s a two-factor authentication key. Passkeys are NOT physical keys.
Is this the same as PGP (pretty good privacy) which has been around for years.
Is it exactly the same? I don’t know. Is it the same concept? I believe so.
Hi, Leo.
Given the clear superiority of passkeys, would you explain why you think it will be years before they become commonplace?
Thank you.
Because it’s additional work — not insignificant — for every website and service that wants to start using them. (Work where a return on the investment isn’t clear, to boot.)
Consider we’ve been trying to get two-factor adopted across the web for years, and we’re still not there.
I’m not poo-pooing the passkey system, but there is always the other side of the story. First, never say that a system is hack-proof because you’ll be proven wrong. It’s only a matter of time. Passkeys transfer the burden of security from the service provider (the big company) to the user. If the user is compromised then it’s the user’s fault (so far) and the service provider can’t be sued for a breach. So, what’s protecting the use of your private passkey on your device? A four-digit pin into your device? Certainly you can layer a biometric login on top of the passkey, but that has its own issues. With passkeys you have to depend on your browser or OS to implement the passkey handshaking and security. So, are we talking about a Microsoft Windows “security” implementation? What about the browser? Whose browser will you trust? Which browsers will be sidelined as unacceptable by a service provider? In other words, passkeys may not be the security nirvana we’re looking for. It’s all TBD.
We’ve long, long said that if your machine is compromised all bets are off. That’s just as true before passkeys as after. My take is they don’t really alter the equation.
Leo, I would like to know if my Private Passkey is on my machine and the drive fails or I get a new machine. What can I do? Am I locked out of all my sites?
Certainly not. It’s exactly like setting up on a new machine, described above. (Passkey Setup #3)
Victor: The amusing story is that your private keys are stored and backed up on the service provider’s servers or the servers of a password manager service (if you use that)! So, you’ll need another access scheme to retrieve your key when you lose or damage your device.
Done properly your private keys are NOT stored on the service provider’s service. By default they’re on only your machine.
If you CHOOSE to use a password manager to manage this, then use, passkeys would be stored there, and would be available once you (re)install your password manager on a new/replacement machine.
Isn’t it sad that great sites like ask Leo are all about avoiding hackers. The internet could be a great information highway for everybody to enjoy. I love repairing computers and working new operating systems. It is always fun to have a computer that will not boot. New challenge today!
Honestly, a world without spammers would excite me even more.
hello there. actually i have to find the exact working on passkeys and try to implement on a local server for its applications , they need to implement passkey on their applications on server with employees phone as private key holder . could you please guide to implement the same or steps to move forward. expecting a positive response from you. thank you
That’s well beyond what I do here. I’d start you here: https://fidoalliance.org/passkeys/
You said that setting up a new account would be authenticated perhaps by sending an email with a link. So, if the public key was disclosed in combination with your email address why couldn’t a hacker then set up a new key on his machine, using your email to authenticate it?
It is not “disclosed”. Each key lives on one and only one machine. And of course if the hacker already has access to your email, you have larger problems.
In the context of Passkeys, the server typically provides a challenge to the user (or client) that must be signed using the user’s private key. Here’s a brief overview of the process:
Challenge Generation: The server generates a unique, random challenge (a nonce) and sends it to the client (user).
Signing the Challenge: The client uses their private key to sign the challenge. This ensures that the client possesses the private key without revealing it.
Response to the Server: The client sends the signed challenge back to the server.
Verification: The server verifies the signed challenge using the public key associated with the user’s account. If the signature is valid, it confirms that the user has successfully authenticated.