Yubikeys have a single master private key, and derive site-specific keys from that. It makes sense in this model not to allow key export. On the other hand, if you have 100 sites you log in to, you can use one key for everything. If you get a new computer, you can just carry on using the same key. If you lose or damage your key, admittedly things get harder.

Passkeys are defined by at least one authority as "resident keys" in the sense that you have one key stored for each site. If you have more than one computer, or your old one breaks and you buy a new computer, you somehow have to get your 100 keys from A to B (and possibly keep them in sync). You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.

Even enterprise HSMs can do this to some extent with key-wrapping. (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)

Personally, the way I'd like key-based authentication to work is something like how SSH keys work currently, where people who know what they're doing can set things up in a way that works efficiently for them. You can choose yourself whether you want 1:n or m:1 or m:n relationships between your keys and your sites and how to manage them.

Because the audience for passkeys is non-technical we are ending up with paternalistic user-hostile implementations that make all the problems the user's.

I don't want to be locked into a platform. I don't want to have to shoulder the burden of making sure I enroll new hardware tokens every few years because I can't just backup / restore the key material in a sensible manner. I don't want one more thing to worry about or pay somebody else for.

I have been using a password manager since 2002. I intend to keep using some kind of password management (password vault, tokens, passkeys, etc) for the rest of my life. I'm worried that the ergonomics of passkeys are very bad and not well thought-out for the long term.

I'm worried the market is skewing in that direction and I will be forced into passkeys and away from passwords to retain access to basic services. I don't really want to be a vassal of a feudal platform lord for my personal password management needs.

Having said all that, you said:

> If you lose or damage your key, admittedly things get harder.

That's worrisome to me. I think the implementers are thinking about it from an "if things go wrong" perspective. I come at things from a "let's have contingencies for when things go wrong".

For what passkeys do I think end users are ill served by the default mode being either user-hostile or feudal.

> Even enterprise HSMs can do this to some extent with key-wrapping.

This. I feel like passkeys are taking the lifecycle model kinds of questions that HSM buyers have to make and thrusting them upon non-technical end users.

Businesses might purchase an HSM with key-wrapped export or backup functionality because they need fault tolerance, disaster recover, and support for key lifetimes that exceed individual hardware component lifetimes. End users don't seem to be getting this choice with passkeys.

It feels like the people implementing passkeys haven't thought about handling those kinds of considerations in a way that provides convenience and security to end users. The answers I see all amount to "Enroll multiple keys for each site. Handle it yourself manually. End users are too stupid to be trusted to handle this well. Tough luck for you if you don't like this beautiful garden we've built for you."

If you're already a password manager user, then it sounds like your gripe is "my password manager doesn't support passkeys." That seems either a short-term issue that would be resolved in time, or you need to find a more powerful manager. It seems the browsers allow passkey providers to be pluggable already, as several third-party vaults support passkeys.

So I see your concern as more "I need to find a password/passkey manager that fits my desires" and less "passkeys require being locked into a platform."

I worry that people who think device attestation and not being able to backup passkey data being good things are too close to the driver's seat when it comes to the direction of passkeys. I see a possible future where free and open source passkey implementations won't be usable because relying parties will want to see device attestation.

I would love to use a hardware device in lieu of a password manager. I just need a tolerable backup/restore scenario.

Apple is playing consumer advocate here by refusing to support device attestation keys on consumer hardware. With the large market share of the iPhone that's a key wedge that should keep things relatively open on the consumer side, presuming Apple sticks to their ideals here. The biggest advocates for device attestation are doing so for corporate "enterprise environments" and that will likely be a dividing line that corporate networks may require device attestation and consumer devices and applications won't/can't.

"Resident keys" is the solution, not the issue.

With U2F it was hard to track which sites used the key. If I wanted to move to a different physical key, what sites should I update to not need to worry about arbitrary account recovery processes? This is one of many reasons I hate SMS verification and why I didn't use U2F beyond a few high-value sites. But with resident keys there is a list of sites I can walk through to migrate or to keep "in sync" with a spare key. Just like with passwords and OTP. Needing to sync them is an existing problem with passwords and OTP; I'd consider it solved, but even if you don't, I don't see why that's suddenly "consumer-unfriendly."

For the service lock-in concern, the resident aspect makes it easier to migrate. Yes, there might be a way to make it easier still, but when the alternative is a physical key it seems a strange demand. I'm the sort of user that'd use a physical key, though, even if the number of available resident key slots is low at the moment.

(If a site doesn't support more than one passkey, then I wouldn't use passkeys on the site.)

> You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.

I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced. We might disagree with each other on which is more important, but I can certainly see a perspective that disallowing export (for a specific implementation) is more important than convenience.

I'm also not sure to what extent the spec / implementers need to provide functionality to work around the fact that some sites are not implementing passkeys properly. That feels a bit icky.

>> I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced.

I see it from the other perspective--not allowing key export is a risk since the user does not have full control of their key and cannot fully manage how it is used.

It is a key and needs to be protected, but not allowing key export / import disrespects the user's choice and freedom and is a perfect recipe for vendor lock-in.

What is the ideal balance between protecting the key and respecting the user's choice and freedom?

There's risks both ways :)

> What is the ideal balance between protecting the key and respecting the user's choice and freedom?

There's no right answer to this. The eternal struggle of mankind is living with the fact that other people have different value systems and therefore end up making decisions that are consistent with their values but that someone else disagrees with.

This is the classic "do you give the user enough rope to shoot themselves in the foot with?" dilemma. Not being able to do what you want with a key that belongs to you? Bad. Having your key stolen because the systems that look after it explicitly let it be exported? Also bad!

> (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)

Bruh

This is akin to CA/B Forum threatening to ban use of OpenSSL because it has a -nodes flag.

The difference is yubikeys have been mainly used in enterprise settings where the reset approach is "get IT to assign a new yubikey to your account or boot your old yubikey". Passkeys are aimed at the general consumer who has been a very rare user of the yubikey. Now you're back to trusting every user to physically keep track of their passkeys, rather than trusting a pool of IT admins.

The export is important in case you want to move to a different service or password manager.

In theory, You should be able to add a new passkey to your account, and remove the old one.

Some of the physical security devices even doesn't support exporting private keys. You ask something (encrypt/decrypt/sign) with a mailbox interface and you get the results. Key is never (and can't be) exposed outside of the secure enclave. Said keys are generated in an isolated RNG inside the key, too. So the system is completely self-contained.

I understand the desire of flexibility and convenience, but this is a tradeoff on a slider. Some designs are full-in on security others are not. We should make choices according to that.

It sounds really really inconvenient when you have a lot of accounts on different websites. Imagine login to add new passkey andremove the old passkey for 100 websites (and my password manager already stores much more than 100 accounts).

Yes, I'm aware that it's very inconvenient. I did the same for my TOTP codes because Google Authenticator didn't restore your keys if your devices were different.

So, I had to manually migrate TOTP secrets from 30+ accounts back then, by removing 2FA, and re-enabling it with a new secret.

As I said before, it's a sliding scale trading off between security and convenience. Select your poison and its dosage, and do your own cocktail.

Or, providers will develop a workflow to migrate or add new devices easily. Like "validate on another validated device to add this new passkey" scheme.

I know, I use yubikeys for all my important stuff.

But I view passkeys as more for the low-hanging fruit. All the crap accounts that every webshop and news outlet makes you create these days. I have 500+ accounts in my current password manager. Not being able to migrate that away to another service would be a nightmare. Being locked in with a big tech company would be too.

What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile.

Also, if software password managers don't offer export options it doesn't mean it's impossible to export. They just don't want to make it possible. But an adversary could. The only way to really make it impossible is hardware tokens which is great for important stuff but not really for those thirteen in a dozen accounts.

> What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile.

That would be glorious. It would be great if it was standards-based, too, to prevent vendor lock-in.

I just looked on github (where I have 4 passkeys registered), and I noticed that the bitwarden one has a little "Synced" flag next to it. The tooltip says "This passkey is eligable for backup by its provider", so sites can distinguish between exportable ones and non-exportable ones.

That's different from what most people mean by "exportable", which is that the provider will give you a copy of the passkey which you can import into another provider.

Syncable means that the provider can backup your passkey to someplace under their control, from whence they can restore it to a different device of yours where you also have that provider's client software.

Here's how Github explains it [1]

> Many passkeys support syncing, where your passkey is backed up by the provider's account system (iCloud, Google account, password manager, etc.). If you ever lose your device, you can recover your synced passkeys by signing in to your passkey provider.

BTW, the flag on Github should probably say "Syncable" rather than "Synced".

[1] https://docs.github.com/en/authentication/authenticating-wit...

That's interesting information, thanks!

I mean the question if private keys should be synced is the fun one to argue about ;-)

My thinking is always if you do passkeys for phishing protection or potentially UX improvements then there is no harm syncing keys. (I would argue the security is increased by adding phishing protection over password/2fa) If you do it for security, then you do not want to sync keys and rely on key storage that do not allow extraction (most secure will be "offline" key stores like YubiKeys). I guess the latter is more important in enterprise/business scenarios rather than in b2c context.

A little OT but it will also be fun in b2c explaining customers that there keystore is full on the hardware key. (of the top of my head YubiKey 5 have a limit of about 25 keys)

If passkey is an additional factor, I'm on the same boat with you. You can sync them all the way down.

But if it's the only factor, I can't see a difference between password reuse and passkey reuse. If I can recover it in any way, then it's (very) game over.

So I'm not mad that you can't sync a passkey if it's the single factor. Because as we don't reuse app passwords for multiple devices or normal passwords for multiple sites, we shouldn't use the same private keys on many devices, allowing a more granular and better approach.

Of course this is my view and some people won't agree. I prefer a good multi-layer system, not a single passkey opens the whole world style one.

Why do you think it is reuse?

You will not use the same passkey for multiple application/service.

You will generate a passkey per application/service.

I will certainly though not disagree on security... if that is your thing then do not sync private keys around, but the tradeoff is always there. If security would be critical, I would favor client certs with smartcards, but browsers do not support that "too well"

If I share the same private key for an account with "n" devices, losing (incl. theft of) that key will lock me out.

If I have "n" private keys for an account, I can use another private key and revoke the lost/compromised one. It's that simple.

Your secure enclave is not much different electronically from a smart card with a biometric password actually. People think Passkeys as SSH keys on disk, but it's more of a long private key on a single-way secure enclave. This is why people cry "platform lock-in". It's platform lock-in, but it's a secondary effect. It's actually a "proper HSM, but integrated".

Yes but the same logic about loosing the secret applies to passwords and any other factors (given we ignore a potential reset process)

Providers will most of the time allow to register multiple passkeys or other authentication means, hopefully ;-) which has its own downsides.

I am well aware how the internals work of keystores. But the benefit with "client certs" is that on mTLS you get added benefits besides where the key is stored. And that is that you can "prevent" mitm attacks.

But I guess that is a subject for another thread.

Resident passkeys really are just the 2020-JavaScript version of X.509-based mutual authentication - naturally it's incompatible with anything but the web, sits on a weird level of the stack, and is somehow even less transparent to the user. On the other hand, certificate slots still seem to run approximately a dollar each.

Haha comparison made me giggle.

When using a passkey as the only factor, it gets complicated, but I think that will be the future: Email and SMS as fallbacks with additional factors like risk-based location checks (or local storage hints) to have a viable recovery mechanism parallel to passkeys. I think Github has a nice approach that we use as a role model: Collect as many fallbacks as possible in a convenient manner. Adding passkeys on any new device and regularly reminding people to check their fallbacks. That's still way more secure than passwords only, where the fallback is practically always a form of email OTP. Also social logins from Google or Apple can act as a fallback as they are (mostly) 2FA.

I'm not against using a passkey as a single factor, and having fallbacks. It's reasonable if you can reliably attach that key to a physical device, so the device can't be impersonated.

I don't think that we should target MIL-xxx standards for daily use, but my security is comparably important to me as military's missile codes are important to them.

So, I don't want my passkey-based services to have a security theater in the name of convenience. There should be some friction to force a baseline security.

Agree, but I think in a B2C context, you need convenience first; then security can follow.

I think it depends. Banking, primary e-mails, etc. are extremely important systems today, and they should bias towards security. Other platforms where we talk can take a more balanced approach, and more casual sites can lean towards convenience, if you ask me.

Indeed, the problem with lots of fallbacks is that they can invalidate user's requests for higher security. Security can sometimes end up being only as strong as the weakest link.

Make the fallback too lax and you might as well not bother with 2FA/Passkeys at all.

Perhaps what you are missing is the "middle ground" here because it is an implementation detail of some of the passkey implementations (especially some of the ones meant to be "consumer-resilient": derived keys. Rather than keeping every key for every site in hardware, you might use some secret shared between the hardware keys plus whatever site-specific salt/pepper/hash into some key derivation function (KDF).

For those kinds of keys extraction is sort of meaningless: the private keys maybe aren't even stored at rest, they are re-derived as necessary. You can sync the encrypted shared secret and all the site-specific salt/pepper/hashes even to devices that can't decrypt them. (That's how secure but consumer-friendly syncing is built, and that's a part of how recovery pathways get built.) But it isn't useful on its own without the hardware keys that you can't themselves export.

You can have syncing with the root keys being exportable/extractable. That's already how many of the consumer solutions are being built. That's part of where the consumer-friendly security is for Passkeys.

Deriving per-domain key pairs from a single master secret is what SQRL did, makes perfect sense for most use cases, allows for straightforward paper backup and transport between devices. https://www.grc.com/sqrl/sqrl.htm

The use case is that I’m an Apple/iCloud user and want to migrate to Google/Linux/whatever and don’t want to go to 100 sites manually to change my passkey?

You actually can backup your webauthn master seed with a Ledger as a 24 word phrase you write down.