2 ms·

I still see problems with recovery. You either have to (a) carry your primary and backup devices with you and risk losing both; (b) lower your security by using

I still see problems with recovery. You either have to (a) carry your primary and backup devices with you and risk losing both; (b) lower your security by using non-hardware-protected keys; or (c) be unable to create new accounts on-the-go. What I would like is a recovery key that I can store in a rarely-accessed safe. Here's an idea from an old paper of mine: on every sign up, you register not only your primary device, but also a recovery pair made of [hash(recovery_token), encrypt(master_public_key, recovery_token)]. Then you keep your single master_private_key in a safe. If you ever lose your primary device, you then: 1. Take your master_private_key from the safe (e.g., printed QR code, backup device, passphrase for key derivation, etc). 2. Ask the service for your encrypted recovery_token and decrypt it with your master_private_key. 3. Ask the service to reset your credentials and use the recovery_token as authentication, to be checked against the expected hash. This way you can create recoverable accounts without carrying your backup key, without downgrading to non-hardware security, without giving personal information like email address for out-of-band resets, and without creating a backup that has to be updated. As a bonus, you can use hash(master_public_key || service_domain) as username for anonymity without extra storage. And this process also works to recover compromised accounts, something you don't get with two Yubikeys that can remove each other.

sebk 4y ago
Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys.
- BoppreH 4y ago
  > Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension Good point, in that they are both based on backup credentials generated on-demand. But the Yubico scheme is a lot more complicated and limited to backup devices (as opposed to passphrase or printed QR code). On the other hand, the signed handover is really cool, and doesn't require the server to store encrypted data like in mine. > In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys. I agree completely.
adrianmonk 4y ago
I'm not a security expert. What's the advantage of creating the recovery_token at registration time? Why can't the site just store master_public_key, and if the user ever needs to do recovery, then use it to challenge them?
- BoppreH 4y ago
  Just for privacy, otherwise the public master key acts as a unique personal id. While there'd be no reason to publish this information, the service can still get hacked, sell your data, or just have a parent company looking for accounts in common among their services.

sebk 4y ago

Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys.

BoppreH 4y ago
> Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension Good point, in that they are both based on backup credentials generated on-demand. But the Yubico scheme is a lot more complicated and limited to backup devices (as opposed to passphrase or printed QR code). On the other hand, the signed handover is really cool, and doesn't require the server to store encrypted data like in mine. > In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys. I agree completely.

adrianmonk 4y ago

I'm not a security expert. What's the advantage of creating the recovery_token at registration time? Why can't the site just store master_public_key, and if the user ever needs to do recovery, then use it to challenge them?

BoppreH 4y ago
Just for privacy, otherwise the public master key acts as a unique personal id. While there'd be no reason to publish this information, the service can still get hacked, sell your data, or just have a parent company looking for accounts in common among their services.