> I personally think these things absolutely should be able to be exported & backed up separately.
I agree. The usual response is that you don't need to do this because you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup.
But managing that sounds like a real pain in the butt to me (honestly, the entire passkey system sounds like a real pain in the butt to me -- but that bit particularly so).
But it looks like the major companies recognize that this is an issue and won't be requiring that part.
It'd be awesome if you could ask to enroll a variety of other devices all at once, without having them on hand.
Requiring ongoing physical access to your crucial backups to do any account enrollment or changes seems like a way to make sure you have your crucial backup way too close to potential disasters. Ideally I wanty backup keys many states away from me. But then I can enroll them!
But it feels like there could be some kind of pubkey for those keys that I could also enroll at the same time as I'm getting my first device.
Except these devices don't have just one pubkey cause that wouldn't be secure. Maybe they pre-make & share 20 keys with a peer device or something. Somehow though data needs to at the end be able to get into the backup/other device too though. Ugh it's wild.
That would certainly be very convenient, but it would also retain/reintroduce several of the security weaknesses that passkeys are intended to mitigate.
The reality is that security is really, really hard. And it remains as true as ever that increased security comes at the cost of decreased convenience.
My personal attitude is that I make different security/convenience tradeoffs for different things. I do have and use hardware keys for very sensitive things. But they're rather inconvenient, so I don't use them for most authentication purposes. Does my account here on HN really need to have the best possible security? No, it doesn't.
So, in my opinion, both passkeys and the traditional username/password mechanism should be supported for most of the web. Which is likely how it's going to be for a long time.
The ability to do auto-enrolment would break the per-site uniqueness of credentials (which makes them pretty strongly phishing resistant under most sane threat models where the browser isn't totally compromised)
Right now, the public key from one token is unique to that site (and specifically your registration attempt with the site, so you can have multiple unlinkable accounts using the one FIDO2 key). If you could do an offline and remote enrollment, you'd need to work with a single static public key (and corresponding private key) for all sites.
Despite all this, I still think this is a use case that's important - both the ability to have an offline backup key (even pairing all your tokens together at setup time to use a common internal root AES key wouldn't help as there's an anti replay counter in FIDO authentications from what I recall), and the ability to use passkeys portably across vendor ecosystems, without relying on a single ecosystem as your trust root.
There are some assumptions in your explanation that I'm not following.
For one, you could generate a new unique private key for the site login, and then encrypt that with the other device's public key. And you could sign it with the active device's key, so that third parties can't try to send you enrollment data.
If desired, you could handle this encryption in a way that makes it impossible for anyone else to tell what keys are being used.
Or instead of generating a private key, you could securely send a single-use token to the other device, and that token allows it to register.
Either way the fixed public key would only be used once, and only directly between the two devices. It doesn't get tied into the site authentication process. And you could replace or augment it with a symmetric key that's unique to that device pair.
> would break the per-site uniqueness of credentials
It wouldn't break things as I've described it. Each device would have a handful of pre-negotiated single-use public keys for the other device it could enroll with.
I tend to think there's no blockers and I just invented a better+obvious flow.
> you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup.
The most common case where people are willing to spend $50-100 for extra security is businesses securing their networks. If you lose your passkey just stroll on over to the help desk and show your id and they'll enroll a new one for you.
If you're an individual using a passkey with free online service, like Github, just enroll a TOTP key first and print out the QR code. Then if you lose your passkey you can use the QR code to get access to your account.
> ... you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup.
Just some problem:
As a backup, I would prefer to store it _away_ from my main hardware key. Everytime I sign up a new service, I need to go fetch the backup and update it...
I agree. The usual response is that you don't need to do this because you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup.
But managing that sounds like a real pain in the butt to me (honestly, the entire passkey system sounds like a real pain in the butt to me -- but that bit particularly so).
But it looks like the major companies recognize that this is an issue and won't be requiring that part.