Comment by BoppreH
7 days ago
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.
I proposed a protocol with this feature almost a decade ago: https://www.researchgate.net/publication/343318317_Privacy-a...
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.
3 replies →
I actually do something like this with PGP: I have my master key stored securely somewhere, and I load subkeys on my Yubikeys.
Would be cool if I could do that with FIDO2!