DRAFT: WebAuthn recovery credentials extension

README.md

This document has moved; its new address is: https://github.com/Yubico/webauthn-recovery-extension

Hi Emil,

Thanks for bringing up the topic on backing up a U2F authentificator. That's one topic which was bothering me a lot.

The proposed WebAuthn extension requires support from RPs, and it means that while some RPs might support it, some other RPs might not, so we'll likely end up with one more non-universal backup method. That's what I really don't like about it; I want to have a 100% reliable backup.

I've made another proposal, totally universal and independent of PRs, and I proved that it works using a open-source U2F implementation, and it will work with every single PR existing today. I explained everything in detail in my article Reliable, Secure and Universal Backup for U2F Token.

What would be your feedback on that?

Hi Dmitry,

Thanks for sharing your proposal. I agree that not requiring code change to RPs is a great benefit, and we (Yubico) have considered something similar, but unfortunately your proposal is only compatible with a subset of the use cases for WebAuthn.

First off, your proposal works only for non-resident (U2F-style) credentials. Resident credentials can't be shared via the wrapping key since they're stored in the authenticator instead of in the credential ID.

Second, sharing private key material between multiple authenticators - or allowing the user to set it - undermines device attestation, which would likely disqualify those authenticators from high-security applications like financial institutions. It wouldn't matter to most RPs, but it seems odd to provide a backup solution that in practice doesn't work for high-value accounts. We could sell authenticators in preconfigured pairs instead of allowing to import keys between them in the field, but then you would need a whole new pair if you lose one of the two, since you can't bind the other to a new backup. That seems wasteful and unfair to our customers.

So although our proposal requires code updates to RPs, it has the advantages that it supports backups for resident credentials and doesn't undermine attestation. Much of the RP validation logic can also be encapsulated in reusable libraries, which should help adoption. For these reasons, we believe this is the best general solution proposed so far.

But of course, as you've demonstrated, there's nothing stopping individual users from using your approach for RPs that don't care about attestation.

Hi Emil,

First off, your proposal works only for non-resident (U2F-style) credentials. Resident credentials can't be shared via the wrapping key since they're stored in the authenticator instead of in the credential ID.

Hmm, but how exactly does your proposal cover the resident credentials? I didn't quite get it from the text above; it only briefly mentions residential creds in "Recovery credential considerations".

Second, sharing private key material between multiple authenticators - or allowing the user to set it - undermines device attestation, which would likely disqualify those authenticators from high-security applications like financial institutions. It wouldn't matter to most RPs, but it seems odd to provide a backup solution that in practice doesn't work for high-value accounts.

So, you're presenting the inability for the user to inject their own key material as a feature? I honestly don't understand. Not allowing the user to inject their own key material just cannot be the advantage for the user, in terms of privacy and everything else. Quite the opposite. Let me just quote Eugene Crosser who happened to leave a comment on my original article: ability to inject your own is important, because it removes the need to trust the the token vendor. If you are limited to the vendor-supplied secret data, you cannot be sure that they did not keep a copy to themselves (because of a government request or for some other reason). When you generate your own secret data, vendor's ability to betray you is significantly diminished.

We could sell authenticators in preconfigured pairs instead of allowing to import keys between them in the field, but then you would need a whole new pair if you lose one of the two, since you can't bind the other to a new backup. That seems wasteful and unfair to our customers.

Why would it be "unfair"? If you only sell pairs, then it might be unfair indeed; but why not provide an option to buy either a single token (as you do now), and, for backup-oriented people like me, another option to buy a pair (primary + backup)? That's not as great as being able to inject my own key material, but nevertheless a huge improvement comparing to no backups at all. I'd certainly order pairs for me and my family.

Hmm, but how exactly does your proposal cover the resident credentials? I didn't quite get it from the text above; it only briefly mentions residential creds in "Recovery credential considerations".

It doesn't back up the main credential directly, but instead creates a dedicated single-use backup credential that can later be used to authenticate creation of a new replacement credential. This works even if the main credential is a resident credential, because the backup credential can always be a non-resident credential.

So, you're presenting the inability for the user to inject their own key material as a feature? [...] Not allowing the user to inject their own key material just cannot be the advantage for the user, [...] Quite the opposite. [...] ability to inject your own is important, because it removes the need to trust the the token vendor. [...]

Yes I am, and yes, you are also correct. Unfortunately, the ability to inject your own key material removes not only the need for the user to trust the token vendor (a good thing), but also the possibility for the RP to trust the token vendor (unacceptable to some RPs). If you can import your own key into a YubiKey, then your bank can't trust that your keys are safe just because you're using a YubiKey, because the YubiKey can't attest to the origin of your keys.

Why would it be "unfair"?

I mean if you have a pair A, B, with B as backup for A, and you can't set up a new key C to back up B once you've lost A and taken out B to replace it. In that case you'd have to get a whole new pair C, D if you don't want to be without a backup for B.

It doesn't back up the main credential directly, but instead creates a dedicated single-use backup credential that can later be used to authenticate creation of a new replacement credential. This works even if the main credential is a resident credential, because the backup credential can always be a non-resident credential.

Thanks for taking the time to explain. However, one thing is still unclear to me: since username is not involved (that's the whole point of resident credentials), a user handle, which identifies the user, is stored on the main authenticator. So when using the backup authenticator, how does RP know which user account to recover credentials for?

If you can import your own key into a YubiKey, then your bank can't trust that your keys are safe just because you're using a YubiKey, because the YubiKey can't attest to the origin of your keys.

I'm not so much into banks and other financial institutions, so unfortunately I'm unable to argue because I don't know. But if it's actually the case and users are considered so silly so they don't have the right to set proper keys to ensure their own security, then it makes me really sad. Also it sounds a little ironic given that these days banks tend to trust SMS, which is anything but secure.

A bit of a side topic: which banks or other financial institutions do you know which support U2F? I'm personally not aware of any bank supporting it, and even paypal doesn't. So would love to learn about banks which do support U2F.

I mean if you have a pair A, B, with B as backup for A, and you can't set up a new key C to back up B once you've lost A and taken out B to replace it. In that case you'd have to get a whole new pair C, D if you don't want to be without a backup for B.

Yes I agree that some users might not like it, but what I'm saying is that it'd be unfair only if the user doesn't have an option to not use the backup at all. If there is an option to buy a single token and live without a backup (basically that's how everyone lives right now), then it's fine.

It's all about tradeoffs, and for someone having to order C+D if either A or B is lost is justified (e.g. for me), for someone it isn't. If there is an option to order just A without a backup (or with a backup implemented as per your proposal, when it goes live, is adopted by PRs, etc), then I don't see any unfairness. Actually I see unfairness in not having an option to order A+B.

However, one thing is still unclear to me: since username is not involved (that's the whole point of resident credentials), a user handle, which identifies the user, is stored on the main authenticator. So when using the backup authenticator, how does RP know which user account to recover credentials for?

Right, good point. Our proposal does not cover accounts that are identified solely by a user handle, i.e., that don't have a username at all. That's not the entire point of resident credentials, though - it's one use case enabled by them, but I expect the most common use case for them will be to ease day-to-day login flows but still have a username to fall back to.

which banks or other financial institutions do you know which support U2F?

I know Coinbase does, although they don't seem to place requirements on the what authenticator you can use. Either way, with regulations such as PSD2 in the EU, attestation will be important if WebAuthn is to be even evaluated for some use cases.

Note to watchers:

This document has moved; its new address is: https://github.com/Yubico/webauthn-recovery-extension