Skip to content

Instantly share code, notes, and snippets.

@emlun
Last active February 20, 2020 15:19
Show Gist options
  • Save emlun/4c3efd99a727c7037fdb86ffd43c020d to your computer and use it in GitHub Desktop.
Save emlun/4c3efd99a727c7037fdb86ffd43c020d to your computer and use it in GitHub Desktop.
DRAFT: WebAuthn recovery credentials extension
@emlun
Copy link
Author

emlun commented Nov 5, 2019

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.

@dimonomid
Copy link

dimonomid commented Nov 5, 2019

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.

@emlun
Copy link
Author

emlun commented Nov 6, 2019

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.

@emlun
Copy link
Author

emlun commented Feb 20, 2020

Note to watchers:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment