There is no truly secure options for this, unfortunately. Passkeys have to be online to enroll additional keys, so any kind of software or smartphone solution is going to depend completely on cloud sync. Any form of offline copy stored in a physical safe will quickly be outdated.
It gets even worse when you want to have separate passkeys, so that you have the possibility of knowing which one was compromised and doing a partial revocation: the cloud sync now requires every device to have access to every copy, so that you can individually enroll them during registration.
Yubikey of course suffers most from this, as their hardware tokens are physically incapable of any kind of sync, so a Yubikey passkey is very quickly a single-point-of-failure. They proposed[0] a system which would allow enrolling a "backup key" (which could then be safely locked in a vault, far away from day-to-day use), but with the various Big Tech companies pushing their own proprietary cloud-synced passkey implementations that of obviously went nowhere.
> Passkeys have to be online to enroll additional keys
No they don't? A passkey is fundamentally just a private key pair, which can be copied around just like a very long password. Of course if you store it inside one hardware enclave and want to move it to another hardware enclave you have a problem, but for software implementations it's simply a client UX issue.
I think "online" here means "loaded in a device", as opposed to "sitting in a safe".
The protocol requires additional keys to sign a challenge during registration, so at best you have to load a pre-generated key from the safe when creating a new account. In practice, you generate a new key for every account, so between generating the key and storing it in your safe there's no backup but cloud sync.
This prevents using backup storage that is safer but inconvenient to access, and also prevents registering accounts on-the-go.
> "Online" in the sense of "loaded in a device", as opposed to "sitting in my safe".
The "device" can be entirely virtual. I've written a passkey-compatible OIDC provider for use on my homelab and it uses passkeys. But the passkeys are just in a SQLite database, which can be copied wherever.
That's not advisable for security, which is one reason I've not released the provider for others to use, but passkeys can operate just fine with that.
If I wanted, the private key itself just be in something like AWS KMS instead of a SQLite database, and it would all still work fine. Nothing about passkeys itself requires a hardware device or that the key be unexportable.
All of which have solutions in this thread too. Nothing forces you to use a passkey provider that enforces attestation if that’s what your threat model worries about.
I admit that the 1+2 yubikey rotation mentioned elsewhere was clever and new to me, but I'd argue that none of the solutions in this thread were good enough.
> Nothing forces you to use a passkey provider that enforces attestation if that’s what your threat model worries about.
I'm very confused by this statement.
For starters, attestation is unrelated to the topic of offline backups discussed in this thread.
Second, the whole problem of attestation, as described in the original post, is that it's not you who decides when to use it. And it's not the passkey provider who enforces attestation, as you said. It's the Relying Party, like Netflix, who can unilaterally decide the minimum security features of my passkey scheme, with all their drawbacks, and attestation ensures that they're followed.
So the problem, then, is with Netflix, not with passkeys. Breaking passkeys to try to prevent some different harm from befalling you does not make sense. And the passkey provider can enforce the lack of attestation by refusing to support it.
Netflix could force you to use a chosen authentication provider to restrict that scenario. But, we already live in that world today, nothing in principle stops them from forcing you to use Okta Verify or Microsoft Authenticator in principle. Yet I do not see people using that as a reason to write articles about how OIDC 2.0 or TOTP is a trap.
> And the passkey provider can enforce the lack of attestation by refusing to support it.
Then you won't be able to use it with Netflix when they require attestation. How's that supposed to help?
> nothing in principle stops them from forcing you to use [...] Microsoft Authenticator
Did you read the article? The author explicitly compares passkeys with TOTP, and explains how relying parties cannot force you to use a specific TOTP provider, because TOTP providers are indistinguishable from the relying party perspective. You could do it with pen and paper and nobody could stop you.
> Yet I do not see people using that as a reason to write articles about how OIDC 2.0 [...] is a trap.
First, there's no such thing as OIDC "2.0". And yes, people do complain about the SSO "Log in with X" services, for precisely the same lock in problems:
Sorry to be blunt, but if your account was not so old I would be reporting you as a possible bot or troll. In my 16 years on HN, this has been my most baffling conversation. I see your other comments on this same post, and you make good points there, I don't understand what's going wrong here.
> > And the passkey provider can enforce the lack of attestation by refusing to support it.
> Then you won't be able to use it with Netflix when they require attestation. How's that supposed to help?
That's my point. The issue is with Netflix forcing you to use passkeys + attestation, not with passkeys existing.
> The author explicitly compares passkeys with TOTP, and explains how relying parties cannot force you to use a specific TOTP provider, because TOTP providers are indistinguishable from the relying party perspective.
I used Okta Verify and MS Authenticator on purpose; they support “extensions” beyond their TOTP support which offer relying parties additional information about authentication events. If Netflix were willing to require atypical passkeys + attestation because passkeys were popular, they should logically be willing to require atypical TOTP + extensions because TOTP is popular. The apps to do this already exist.
I have government websites that already require me to use Okta Verify specifically, but I don’t go around saying this is the fault of TOTP for existing.
> In my 16 years on HN, this has been my most baffling conversation. I see your other comments on this same post, and you make good points there, I don't understand what's going wrong here.
We might just be talking past either other. I have been guilty of it before.
Most website implementations that support passkeys have to support multiple key enrollment. It's the only long-term reliable way for the many, many users that are cross-ecosystem, which especially means Windows users in the age of no Windows Phone. Every Windows user has either an Android or iPhone. You can bootstrap with Bluetooth LTE access to your phone for a Passkey, but it's a rough web experience if the user needs to do that every time they access a page, so most good flows ask the user the enroll a Windows PC passkey in addition to their phone's passkey and really good ones make use of a passkey auto-enrollment option designed for this scenario (Bluetooth passkey to "local" passkey auto-enrollment).
Perhaps surprisingly, Windows has helped keep Passkeys from being "proprietary" lock-in because Microsoft no longer has users in a single ecosystem.
There is no dedicated auto-enrollment for "backup" keys, but most consumer sites make it very easy to enroll "backup" keys yourself.
Also, Passkeys don't have to be "online" to enroll additional keys. Each key is independent, enrolling is just generating new keys. The trouble is that web browsers generate lots of Passkeys (at least one per domain, at the very least) so if you in theory want to print them all and store them in a physical vault it might be a hefty book you are printing.
Cloud sync isn't required. Most users want it so that they don't have a single-point-of-failure.
As an implementation detail some Passkeys have a master key that is then used in some key derivation function (KDF) to generate the hundreds or thousands of individual passkeys (at least one per domain), and that's what most Yubikey passkey implementations need to do because Yubikeys weren't designed to store lots of keys, so it is devices like Yubikey that makes it seem like Passkeys are less independent than they really are.
> so a Yubikey passkey is very quickly a single-point-of-failure
It is a single point of failure when there is one. As soon as you use two, then it's not a single point a failure anymore, is it?
The counter argument I usually read is: "Yeah but it is not practical, because you need 3 yubikeys: the first 2 with you, that you enroll everywhere, and one in a safe. And every time you add a new passkey, you need to go get the one in the safe, replace it by another one, and enroll the one of the safe. You can't spend your life driving between your desk and your safe".
But I have been using multiple Yubikeys for... 8 years now I think? I don't remember the last time I enrolled and important key. Sure, once in a while I add a website, and it is a bit annoying to have to enroll the other Yubikeys at a different time. But it really doesn't happen that often, and anyway most of those websites allow me to recover my account with my email. So it is actually practical to have a "convenience yubikey" for websites that don't matter so much, and in case this Yubikey dies... well those websites were not so important, and anyway I can recover from my email.
The difference for the important websites (and really, I don't think I have really important websites in my life that don't allow me to recover by going in person with my ID, but for the sake of the argument) is that I actually do have multiple Yubikeys, one of which is stored away.
Whereas the master password of my Bitwarden account is a single point of failure, and the security of my online Bitwarden account is as well.
That's a clever setup that I hadn't seen before. Some extra downsides:
- Relying on emails for account recovery prevents creation of anonymous accounts.
- Have you ever lost your "convenience yubikey"? People underestimate how painful mass account recovery can be.
- The cost of 3 yubikeys can be substantial for some demographics.
- Important accounts are not properly backed up until you drive to your safe. That can be many days for a bank deposit box, or even longer if you're traveling.
Overall that's a lot of compromises for what should have been just "put this recovery key/password in a safe and forget about it until needed", if the protocol was better. And definitely not something that can be widely recommended.
> ... just "put this recovery key/password in a safe and forget about it until needed"...
Surely that is also impacted by:
> Important accounts are not properly backed up until you drive to your safe. That can be many days for a bank deposit box, or even longer if you're traveling.
Nope! You could have one "master recovery key", the public part loaded on your device (to be registered during account creation) and the private part sitting in your safe. Or even a number of pre-generated recovery keys. You could also give those keys a higher "priority", since they're offline, so that they can revoke lesser keys in case of account compromise.
The problem is that the passkey protocol prevents you from adding a (additional) key you don't currently control. This is what crote was referencing here:
> Passkeys have to be online to enroll additional keys, so any kind of software or smartphone solution is going to depend completely on cloud sync.
> You could have one "master recovery key", the public part loaded on your device (to be registered during account creation) and the private part sitting in your safe.
This is true, it's possible to have just the verification information present without the key itself.
However, a part of almost every credential enrollment process is verification that the credential is usable and controlled by the enrolling party.
For passwords it's simply "please type the password again", for TOTP it's generating the next number, for email/SMS it's entering a code sent to that address, so for adding a public key, it should include some way of verifying that you control the private key associated with that public key. It's hard to do that without having the private key available.
> For passwords it's simply "please type the password again", for TOTP it's generating the next number, for email/SMS it's entering a code sent to that address
Those are strings typed by humans and frequent victims of typos, so the need is much higher. But you're right that it's still useful to prevent a user from accidentally using a bad key, or from selecting a maliciously formatted public key to mess with the protocol. I just don't think these benefits outweigh the lost ability of making offline backups.
Maybe allowing registration of multiple keys, but only requiring proof of possession of one key would be a good compromise.
> but only requiring proof of possession of one key would be a good compromise.
Prove that you possess one key, and sign the other public keys with that key you possess? That would prove that you possess the public keys, wouldn't it?
I guess my concern would be that I have the public key to my backup Yubikey on my computer, I enroll it everywhere but I never actually use the Yubikey because it is stored in a vault at the bank. Nothing prevents an attacker from replacing my public key with theirs, and suddenly I'm enrolling them everywhere without ever noticing.
> and suddenly I'm enrolling them everywhere without ever noticing
That's a clever attack and it indeed seems viable.
In my proposed protocol the public recovery key defines a "profile", and the account "username" is generated based on this key plus the service domain. So an attacker replacing this key would be reflected in the app as a completely new profile, and cause all your logins to fail. Not a perfect mitigation, but something.
I would be happy with that already, but I think even better solutions might exist.
Another issue of using one "master recovery keypair" naively with passkeys, is that you have to register the same recovery public key on every service, losing your pseudonymity. In my protocol that's not a problem because the recovery key pair is used for decryption, not signature, so the "public" key is never shared. Also, all these services already require an email anyway.
(I'm not trying to advertise my protocol because I never figured out a good way to do multi-device sync without trusting the cloud or having bad ergonomics. SQRL solved it by having deterministic keys, but that makes much worse the problem of a past leak compromising your future accounts)
> Nothing prevents an attacker [...]
I mean, hopefully the device security does! That's as bad as someone adding a hidden forwarding rule to your email account, or adding a new device to your password manager cloud sync.
> I have been using multiple Yubikeys for... 8 years now I think? I don't remember the last time I enrolled and important key.
This probably makes your use case somewhat unusual...
> I actually do have multiple Yubikeys, one of which is stored away.
...and this probably puts you in the 0.0001th or so percentile of users. It's really a great security strategy if you can pull it off, but practically almost nobody can.
Not sure what you mean. "Normal people" have to enroll important keys much more often, and cannot use multiple Yubikeys?
My feeling would be that "normal people" can always recover their accounts from their main email, which makes the main email the only "important" account. So having a Yubikey always plugged in is a "nice convenience".
Now to be honest, I would expect that "normal people" are absolutely fine with passkeys on their smartphone, and don't consider it a "trap".
I would just expect that people who consider it a trap are able to use a Yubikey the way I do.
I use Yubikeys for WebAuthn 2FA (not as passkeys). Keeping them in sync is not a big issue in practice: I just don't sign up for new services that often. There's a stable set of services I'm using and it is rare that I actively look for something new. Usually it is the other way around--how do I use this thingamajig without creating an account.
Why would cloud sync never be "truly secure" (no such thing btw – security is always a tradeoff, availability also matters etc.)? A hardware root of trust and credential synchronization are not mutually exclusive.
True, most solutions today don't do this, which makes onboarding of fraudulent additional instances to some cloud-synced vault a big security concern, but I don't think it's fundamentally impossible.
Not mutually exclusive, as long as you have a trusted mechanism for establishing mutual trust between hardware roots. How do you achieve this when one of the roots is a distributed cloud service, provided by a third party?
It gets even worse when you want to have separate passkeys, so that you have the possibility of knowing which one was compromised and doing a partial revocation: the cloud sync now requires every device to have access to every copy, so that you can individually enroll them during registration.
Yubikey of course suffers most from this, as their hardware tokens are physically incapable of any kind of sync, so a Yubikey passkey is very quickly a single-point-of-failure. They proposed[0] a system which would allow enrolling a "backup key" (which could then be safely locked in a vault, far away from day-to-day use), but with the various Big Tech companies pushing their own proprietary cloud-synced passkey implementations that of obviously went nowhere.
[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...