Comment by degamad
6 days ago
> 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.
Or am I missing something?
> 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.