It’s a bit of math, split into two pieces.
You hand out one piece, that’s the public key. It’s tiny and simple.
You keep the other piece, that’s the private key. It’s long and complex.
The public key can scramble data that only the large piece can unscramble.
The private key can create a piece of data that only the public key can verify.
In practice, these keys can be kept in a database or a file, and they can be held in a hardware security key (yubi/fido). They can be stored on your phone, in Bitwarden, and just about anywhere that keeps passwords, they’re really just a few thousand bytes of data.
In many cases, You can store them in your phone’s private password storage, then when you log into a website, it will trigger a popup on your phone to authorize your login, so you don’t even have to keep them on the computer you’re using to access the secured site. Most of the implementations require you to have a biometric component. You need to face scan, fingerprint scan, or, worst case, use a password to unlock/verify the passkey on the device.
The upside here is that the keys are unique to every site. The public key is completely safe to hand out to everyone, it can’t be reverse engineered. This means that websites can’t leak your login credentials in any meaningful way. edit: Also since you’re using math to change a piece of data, it’s impervious to a replay attack and the communication even unencrypted would be reasonably safe even if someone was actively reading it.
As far as storing for loss, I’d consider regenerating them. I prefer using a password manager that stores them, that way my phone/computers all have access to the same keys.
Is it any different than public/private ssh keys that I already use? Or just a rebranding?
Not the op, but afaik they’re just a new implementation.
Unintentional trick question :) SSH can use a ton of different crypto, so can passkeys (The actual Fido Spec if you want to read about it is webAuthn).
While they both support RSA, The WebAuthn default appears to be RFC-8152 https://www.rfc-editor.org/rfc/rfc8152 in an attempt to try to keep the sizes down.
If you’re talking about what Google or Microsoft offer as a login tool, it’s basically a file hidden on your physical PC so when you attempt to login to a service that wants it, the service gets a password from you and the passkey from your actual device to authenticate you.
For example, I have passkey enabled on my windows PC that my Google account has a passkey in. Anytime I access the built in password manager in chrome, Windows now gives me a pop up for a PIN number, and then windows will authenticate on my behalf with the hidden passkey.
If I need to access my password manager from my phone or another computer, I have to use my Google password instead since my passkey isn’t on those physical devices.
I believe Microsoft stores your passkey files on your motherboards TPM module, but I could be wrong.
As far as I understand it, passkey is a password replacement and a protocol built on top of FIDO.
The intention is to replace passwords by cryptographic keys (asymmetric encryption). These keys come in pairs always:
- a private key: secret and only ever known to you
- a public key: given to the service you want to authenticate to. This key can also be seen as a lock that can only be open by the matching private key.
The keys are nothing more than text and they can very well be stored in files on a USB drive, copied, transferre, deleted, etc.
But passkey also defines the process to exchange and store the keys in a secure manner. Therefore in practice you will always use a password manager and maybe also some specific hardware, to automatically hand the key exchange and secure storage of all the different keys your have for all of the different services you registered to.
An article I read recently suggested that storing passkeys with Google, Apple, and M$ didn’t have interoperability. Like you need a Mac/iPhone or PC/Android to make it work. Is this true? Can I store a passkey in a platform agnostic way?
Aside from platform agnostic password managers having support for it as a commenter below pointed out you can also save it on a physical “hardware security key” (e.g. yubikey). Technically this should be the best option as there is no way for anyone to steal your passkeys unless they physically take apart your hardware key (and there’s even keys that have additional protections that make it impossible to take apart without destroying it).
However every single platform really pushes people towards using their own solution. So only their solution is neatly integrated in their platform and also preselected when you save a passkey. But all in all those are rather small hurdles for the security a hardware key gives.
Can I store a passkey in a platform agnostic way?
Yes, if you use a platform agnostic password manager that supports passkeys such as Bitwarden.
Can I store a passkey in a platform agnostic way?
If by “platform” you mean OS, then yes - and the best way to do that is to use a dedicated password manager instead of something that’s tightly integrated with an OS.
That said, iCloud keychain is available on Windows, but not Android. Likewise with Google Password Manager - it supports Macs, but not yet support iPhones or iPads.
However you can also use a password manager like one of these and use it across every platform:
- Bitwarden
- 1Password
- ProtonPass - Passkeys Help Article
- Roboform - Passkeys help article
- Dashlane
- NordPass
Based on my experience (with Bitwarden) or research, all support passkeys in browser extensions for Firefox and Chromium browsers and/or desktop apps on Linux, Mac, and Windows, as well as in apps for iOS and Android.
Keepass also might be an option, as KeePassXC supports passkeys and is available on Mac, Windows, and Linux, but I didn’t see any mobile clients that advertise support for passkeys.
Even with the more open password managers, there isn’t a built-in way to transfer passkeys from one password manager to another. However, the FIDO Alliance is working on a spec for securely transferring passkeys so hopefully that’ll change soon and you’ll be able to transfer passkeys from one ecosystem to another.
Also, you can generally still log in on a device that your passkey service doesn’t support by scanning a QR code displayed on the target device on your phone, so long as both devices have Bluetooth (used for confirming physical proximity). I’ve only done that once and it wasn’t super streamlined, but it also wasn’t terrible. You can also save passkeys to your phone or security key (like a Yubikey) though be aware that a YubiKey 5 can only store 100 passkeys. And you can have multiple passkeys to a given service, so if you use a Mac but use an Android phone, you can save a passkey to iCloud Keychain on your Mac and to Google Password Manager on your phone.
EDIT: Looked up and added the correct limit for YubiKey passkeys
Basically dedicated 2FA hardware.
If you lose it, you’re fucked, end of story.
You do not need specific hardware to use passkey. For example you can use a password manager like Bitwarden and have your passkeys sync between multiple devices, including a good old regular computer.
Specific hardware car be use to secure how the passkeys are stored. For example, smartphones usually have a security chip that help s with storing encrypted data.
Your milage will vary with your corporate policies. You’re not wrong, but you’re not completely right.
I can’t just pick up any smartphone and install a passkey manager on it. It has to adhere to some specific hardware requirements (like a dedicated chip or instruction set on a CPU).
So yea, in standing by the 2fa dedicated hardware line. It’s easier than getting into the weeds on hardware device configuration.
Your milage will vary with your corporate policies.
What does this have to do with anything?
I can’t just pick up any smartphone and install a passkey manager on it.
Sure, because “any smartphone” includes smartphones that don’t turn on, that are locked with a passcode you don’t know, or that are running a 10 year old OS.
Which modern smartphones (meaning, still supported by its manufacturer and running a current OS, i.e., iOS 17/18 or Android 14/15) don’t have passkey support? I don’t know of a single one.
My voice is my passport, verify me.
A passkey is a super general term. It’s usually something you can store in a file (because you can store any data in a file) though sometimes it may have a hardware element. You can probably save your passkey in a file and you certainly can copy it onto a USB drive.
You can also save passkeys into password managers which is what I personally do so (coupled with a syncing script) I can access it from any of my devices.
That makes it sound like it’s a password. If a passkey can be saved in a password manager, can it be memorized or written down? What makes a passkey different than a password? Or are they just two ways of saying the same thing? Is it a really long password that makes you dread having to type it in, or even worse, enter it in with a virtual keyboard with a remote with arrow buttons?
Imagine a password about 80000 characters long.
No, the cryptographic keys used in passkey are not just very long passwords. In face they are not so long. Typical keys generated with ed25519 are 60 characters long.
Ah, i can’t find the thing i read now so I’ll assume you’re right.
The key difference is that during normal use, the private key of the passkey doesn’t leave the device (or password manager). The passkey basically comes in 2 parts, the public and private (secret) part. In order to log in, the website presents a cryptographic challenge that is only solvable using your private key - and crucially you can solve the challenge without revealing your private key. An attacker could get your answer to the challenge and still be unable to solve additional challenges without the private part of your passkey.
This of course makes it basically impossible to manually log in using a passkey and a keyboard, without any password manager to do the cryptographic calculations (unless you have a LOT of paper and time), but the security advantage of making it near impossible to be phished is generally regarded as a net positive. In order to steal a passkey there would need to be a vulnerability in the software, since passkeys make it much harder to trick a user into giving it away (since tricking the user into logging in on a fake website doesn’t work due to the aforementioned cryptography, the main way to steal a passkey would be to trick the user into exporting it - which is a much higher bar).
Everything in a computer is data - passwords are no different from novels and you could use War and Peace as your password as long as you hated whatever system needed to check it.
Passkey is usually used to describe a password you keep in a file usually with a public/private pairing though, with everything computer, this is only the general form and description.
I mentioned putting it in a password manager because, as mentioned, it’s just a string of text… if you want you can put the full executable bundle for Starcraft2 in your password manager - most have trivial ways to copy in whole files but, again, it’s just data.
To try and bake down the complex answers, if you are basically familiar with PGP or SSH keys the concept of a Passkey is sort of in the same ballpark. But instead of using the same SSH keypair more than once, Passkeys create a new keypair for every use (website) and possibly every device (e.g. 2 phones using 1 website may create 2 sets of keypars, one on each device) - and additionally embeds the username (making it “one-click login”):
- creating a passkey is the client and server establishing a ring of trust (“challenge”) and then generating a public and private pair of keys (think
ssh-keygen ...) - embedded in the keypair is the user ID/username and credential ID, which sort of maps to the three fields of a SSH keypair (encryption type, key, userid optional in SSH keys) but not really, think concept not details
- when using a passkey, the server sends the client a “challenge”, the client prompts the user to unlock the private key (device PIN, biometric, Bitwarden master password, etc.)
- the “challenge” (think crypto math puzzle) is signed with the private key and returned to the server along with the username and credential ID
- the server, who has stored the public key, looks it up using the username + credential ID, then verifies the signature somewhat like SSH or PGP does
- like SSH or PGP, this means the private key never leaves the device/etc. being used by the client and is used to only sign the crypto math puzzle challenge
The client private key is stored hopefully in a secure part of the phone/laptop (“enclave” or TPM hardware module) which locks it to that device; using a portable password manager instead such as Bitwarden is attractive since the private keys are stored in BW’s data (so can be synced across devices, backed up, etc.)
They use the phrase “replay” a lot to mean that sending the same password to a website is vulnerable to it being intercepted and used n+1 times (hacker); in the keypair model this doesn’t happen because each “challenge” is a unique crypto math puzzle generated dynamically every use, like TOTP/2FA but “better” because there’s no simple hash seed (TOTP/2FA use a constant seed saved by the client but it’s not as robust crypto).
- creating a passkey is the client and server establishing a ring of trust (“challenge”) and then generating a public and private pair of keys (think
If you mean the “passkeys” that are becoming popular as a “password replacement”, it’s basically speaking a public private keypair. What makes it more secure is that, under normal conditions (aside from backing up the passkey), the private “secret” part of the keypair never leaves the app or device it’s stored on. It’s only used temporarily to sign messages and prove that you have the secret key, unlike a password which needs to be sent securely to a server to validate.
You could in theory store a backup on a USB drive but since passkeys are new, it highly depends on the password manager you use to store the passkey. Since passkeys are more complex than something you can memorize/type, it has to be stored in a password manager of some sort to be useful, so you would need to check that password manager allows backing up passkeys. There is currently work being done to standardize the formats/protocols to transfer passkeys so it seems this is very much up in the air. For example, I use BitWarden which stores passkeys,
but it seems like I can only add or delete passkeys to an entry, not export themand apparently they get exported with the passwords when the vault is exported. BitWarden also syncs your vault to every logged in device though so you could see that as a form of backup. Going one step further,even though BitWarden doesn’t have a passkey export/backup feature yet(in addition to Bitwarden’s vault export), the self-hosted server also stores all your passwords including passkeys in regular files which also can be backed up (this is how I back up my VaultWarden instance) - although it would probably be hard to use that backup in any other way besides restoring it onto a BitWarden server instance.Edit: I didn’t realize passkeys were exported with the vault export, since I haven’t used it and noticed that editing an entry doesn’t allow you to view passkey data - only remove, updated my comment to reflect that.
Bitwarden exports passkeys when using the .json export format
Oh nice, I completely forgot about the vault export since I’ve never used it. I was expecting to be able to “view” the passkey data when editing an entry like how you can view the password. It’s kind of inscrutable when viewing a single entry currently.
What are the benefits of a passkey over a client certificate?
What are the benefits of a client certificate? As an end user, I’m pretty sure I’ve never used one.
I don’t know much about client certificates, because nobody ever used them. All I know is that they are decades older than passkeys, and “certificate” implies there is a public-private keypair, just like in a passkey.
If I were talking about Passkeys and comparing them to client certificates, even though I don’t know much about client certificates in practice, I would say:
- Passkeys can be installed in your password manager, which handles securely syncing it to all of your devices
- Websites can make it very easy to create or log in with a passkey
- Far more websites support passkeys
- Websites can support multiple passkeys per user
- The user experience is far better with passkeys
- Even if your password manager isn’t installed on a given machine, you can still log in with a passkey via your phone, so long as both devices have bluetooth enabled. This allows you to log in on an untrusted device, like a library computer, without exposing your password (though unfortunately that would still result in that computer having access to the session and being able to modify account settings - best practice would be to log out when you’re done and then, from a trusted device, confirm that you were logged out / log out of all devices.)
Passkeys are basically client certs for website logins.
Server stores a public key, encrypts a challenge on login attempt. Client browser uses private key to decrypt challenge (and sign it maybe?) and respond to web server to authenticate.
Hackers can’t get a shared secret (like a password or password hash) by hacking the website’s database becaus the public key is all they store; useless without the private key.
Not foolproof, but much harder to exploit than passwords - which many people re-use across multiple sites.
