[nano9]

The same could happen with a hardware token like Yubikey, if it were to suffer from an irrecoverable software or hardware error. It's still useful, because spoofed authentication prompts will no longer get a chance at plaintext access to your password.

[kitsunesoba]

This is also why it's a good idea to have multiple keys instead of having everything riding on one. With a T2/M-series machine it's easy to have at least two (one in Secure Enclave, one in a USB key), and USB keys are tiny enough to hide away another one or two.

[filleokus]

I've always felt that the suggestion of having two keys seems kinda cumbersome, especially for webauthn. If understand it correctly I need to enroll both keys, by physically having them present? Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective).

For SSH it's probably easier since I can just have both public keys accessible for adding it to new servers and keep the token somewhere safe.

My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device.

That way I could just restore the same private key if the physical secure enclave is destroyed.

[Avamander]

> If understand it correctly I need to enroll both keys, by physically having them present?

Yes.

> Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective).

Alternatively you print out the backup codes.

> My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device.

The primary reason why we want to do hardware at all, is that to the best extent we know the key is generated by it and will remain in it. That most of the threat becomes someone in the physical world stealing it from you.

Though some more open-source webauthn tokens would allow you to do what you described. Secure key management procedures are just not something we should encourage people to do themselves, it's difficult.

[filleokus]

> Alternatively you print out the backup codes.

But those are per site right?

Re hardware and that above is not something for most people:

Yeah I agree. Something like https://uni.horse/notes/solo-key-backups.html, but it shouldn’t be a solution for most people.

But I still think the backup story is flawed, and could be improved to work in a easy and secure way:

Using some easy vendor GUI tool, with a simple clone button:

1: Generate on-hardware webauthn master key on device A. 2: Generate on-hardware key-par on device B 3: Export B’s public key to A 4: Encrypt A’s private key with B’s public key 5: Export encrypted master key to B 6: Decrypt on B

But I guess we ideally would want some standardized protocol for doing this so you can do cross vendor backup.

[kitsunesoba]

Personally I don't think I'd bother with redundant keys for most sites/services, only for those of the greatest importance. I think for most of us that list is short enough that redundancy is manageable.

[filleokus]

Probably true. But my point is that if there was some secure/easy way to clone a key you wouldn’t need to think about redundant keys at all. If you create a clone you get redundancy for all sites in one sweep

(Most likely this will be solved by the mobile os vendors who will sync and backup your private key for you. Using your phones HSM instead of an external device)