You shouldn't ~~necessarily~~ need to "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.

Similar to SSH keys. No reason to use the same key on all your machines, use a different key from different places.

The passkeys on my laptop are different from the passkeys on my desktop which are different from the passkeys on my phone which are different from the passkeys on my main yubikey which are different from the passkeys on my backup yubikey.

Edited due to acknowledging people may choose a variety of alternative workflows.

> You shouldn't necessarily "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.

If he's storing his passkey in his password manager, it wouldn't matter that he lost the device. They can't get to it, it's AES-somebigassnumber-ed up the wazoo. If the passkey is cached outside of the password manager, then passkeys are a horrible idea, where you have to "go home and call the 800 numbers to cancel the credit cards", and worse still, people with few devices might end up in circumstances where they have no valid devices left to bootstrap access.

I am resigned to the fact that I will die with humanity never having solved the problem of passwords adequately, but being that I will live another two decades minimum, I will get to see two more of the stupidest possible non-solutions.

That's assuming the user does have a strong passphrase to protect their local password safe and the device wasn't compromised while the password safe was in an unlocked state.

If an attacker managed to get root on my machine right now, they'd get my whole password safe as its currently decrypted and in memory. However, they wouldn't be able to access any of my passkeys.

And if they get the passkey's private key, when you're signing some ticket to send off to prove identity? That has to be unlocked for that too, it's in memory somewhere.

Then they privilege escalate, lock out all your other devices after adding a new one, it's the same issue. And it's opaque, reinforces the ideas that users are too stupid to do anything right, so that we shouldn't even try.

> That has to be unlocked for that too, it's in memory somewhere.

Its in-memory on my physical hardware token or a TPM or a secure-enclave, which only activates and unlocks after a valid identity challenge (fingerprint, physical touch, face scan, pin, etc.) not my main system's userspace memory. A massively different target.

I use far more sites than I ssh into servers, which makes this much more of a pain. Like, every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop? If all my devices are destroyed in a house fire again, I'm locked out of everything? These have been my big concerns.

> every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop?

You don't need to log in to every app on every device the instant you register a new account. Just make a passkey on a couple of devices that you're likely to have around and you'll probably have what you need when you need it. When I register on a new site that uses passkeys, I might create a key on whatever computer I'm on and a portable authenticator like my phone or my security token.

So, say I'm at home on my deskop, and TotallyCoolService has the option for a passkey. I'll make one on my desktop, and then go ahead and make one on my security token. Later I'm out and I want to check in on TotallyCoolService on my phone. No worries, I just tap my security token to my phone and I'm logged in. Later I'm in the garage working on my motorcycle and want to reference something on TotallyCoolService on my laptop and my USB token is in my backpack inside. No problem, I can sign in with my phone. Now I've got security tokens on most of my common devices and its not like I had to spend time gathering all of them at account creation.

I don't instantly run home to my desktop and log in the moment I sign up for a new site while out and about. But I do go and sign in eventually, even if only to ensure there's a backup key there.

This really doesn't contradict the problem of needing to sort out M sites x N devices, where M can be very large.

Whether you do it eventually or do it straight away. Unless you can predict which devices you will have and which sites you will need access to at any given point, then it degrades to needing everything authenticated just in case.

I'm pretty much never too far from either my phone and my security key, seeing as how at least my phone is my car key and my wallet the majority of the time and a security key lives in my backpack.

Sure, M devices can be quite large, but the odds of me being at only one device and not any of my portable devices is extremely small. As long as I have at least one other device I've previously logged in to somewhat handy, I can still easily get in. Maybe that initial login is marginally more complicated, but IMO the ease of future authentications more than makes up for the small bit of initial friction the first time.

And in the rare instance where I'm suddenly on the moon and realize I left practically every other computing device and physical authenticator on another planet, I guess I just won't have access to a DnD tool. Oh well.

> No worries, I just tap my security token to my phone and I'm logged in.

What allows you to tap your token on your phone and register a passkey-stored-on-phone registered with TotallyCoolService? Did you previously set your phone and token to be "mutually trusted devices" in some way?

Or what's preventing a thief from tapping my token on their phone to register it on TotallyCoolService?

It requires a PIN to give a resident key, and too many pin failures wipes it.

Other authenticators have biometric requirements.

I see. So the weakest link in the security chain is that someone discovers the <6 digit pin on your usb key (easy on a security camera), and then manages to steal it for 2 min.

Not terrible for anyone whose threat model is not targeted attacks. But quite bad for people whose threat model is exactly that.

Great in theory, but in practice there are still a frustrating amount of websites and services that put a low upper limit (usually just one or two) of the number of keys you can enroll.

This effectively makes it impossible to do what you’re saying. It sucks.

I hear this a lot but it hasn't generally been my experience. The only site I've personally come across that supports webauthn/passkeys but doesn't support multiple is the AWS management page. Which I essentially bypass by just configuring SSO and using an IdP which does support it.

Every other site I've come across that supports these things supports multiple. What common sites support only one or two?

AWS now supports multiple MFA devices per account.

That's awesome to hear, thanks for sharing!

PayPal is a big one. It allows you to have exactly one passkey.

Yo. Thank you so much for posting in this thread. Turns out I was thinking about Passkeys wrong this whole time and you're the first person (I've seen) to really explain this workflow. Thanks again!

Actually, I much prefer to use the same SSH key for deployments from any of my machines, so that example doesn't really work for me (I do have multiple keys).

How do I then get the passkey for my second device accepted by the service? Do I mail the public part to myself and insert it from my first device?

The first time I log in to a service on a new device it'll prompt me to sign a challenge with a previous passkey. If I've got my yubikey handy I'll just plug it in and sign it and add a new passkey to my new device. If I only have my phone the site will flash up a QR code I scan with my phone which signs and posts back the proof to a callback URL for the site. I only need to do this once per device if I add a passkey to the device.

Is the fact that you need access to an already- enrolled device to create additional passkeys part of the threat model that passkeys resolves, or just an annoying detail? And is this for every site, or just once per device? I can just look it up, this thread has been great to improve my mental model enough to start considering trusting it.

Its per-site. So the first time I log into GitHub on a new device, I need to do the handshake with another device. The first time I sign into Coinbase, I need to do the handshake with the other device.

So this typically means when I get a new device I'll have my Yubikey in a bag or something with me for a while and pull it out from time to time. Eventually practically every site I use gets enrolled on the new device and I never actually need to reach for the Yubikey or my phone or whatever.

I don't really make any concerted effort to go through each and every account when I get a new device, it'll pretty much just happen eventually. When I do sign up for a new account that supports passkeys I do try and make an effort make a passkey on at least two devices though, often at least whatever device I'm using to initially register and my yubikey. Then I'll make a point to log in sometime in the next few weeks on another computer and create a passkey there. Eventually I'll probably end up logging in and making passkeys on most of my devices.

Needing to auth with an existing passkey is a major part of the model. If you could just log in and create a new passkey with just a regular password, what's the point?

I've installed KeePassXC on my Mac and Linux machines and it stores Passkeys. Low-tech syncing is by Signal Notes to Self. If there were an audited app for iPhones I'd still be using that method; there isn't, so I've moved to Bitwarden. Passkeys seems to work fine on Bitwarden.