Portability of private keys

[valentin-huebner]

Since this standard is intended to be able to replace password-based logins, there is one issue that I think needs to be addressed: When the user signs up for an account with a password, they can create backups of their credentials. When they sign up with WebAuthn, by the nature of a secure environment they cannot extract their private key from the authenticator (unless it's purely software-based, like Windows Hello). So if they lose it, that's like losing all your passwords.

Are there any plans to prevent such a situation?

[limpkin]

I'd say this is up to the authenticator manufacturer...

[emlun]

Yes, this is outside the scope of the WebAuthn spec.

The position Yubico has taken for our Security Key and YubiKey authenticators is that private keys can never leave the authenticator. One reason for this is the issue of attestation: the attestation statement sent in a registration request attests that the private key is created and owned by the authenticator, and has never been exposed to any other party. If it were possible to import a private key from outside the authenticator, we would not be able to attest this.

The backup strategy we recommend instead is to have a second authenticator as a backup, and register both that and your primary authenticator with each site. Then if you lose the primary authenticator, you can fall back to the backup authenticator while you set up a new primary authenticator.

[valentin-huebner]

I agree that the private keys can't ever leave the authenticator. But just having two of them is not a viable solution either: To be able to sign up for a new service e.g. from my office, I either have to take both of them with me. Then if I lose my briefcase, both are gone, so the point of a backup which is redundancy, is lost. Or I could remember to set up a second key on my backup authenticator at home. I might easily forget, and only notice when it's too late.

I think what we should have is a standardised duplication protocol, so that a duplicate of one key can be registered for another authenticator without me having to click through things in the browser. So at any time, I can plug in my USB backup authenticator and it syncs with my phone or laptop by registering a duplicate of every new credential (after confirmation on the primary authenticator). That has some privacy implications (the RP knows when I'm syncing my backup), but we can't avoid that anyway other than by either not creating a backup at all or releasing data from the authenticator.

[emlun]

Yes, those are legitimate issues we (Yubico) haven't yet solved, and WebAuthn does not yet attempt to solve them either. On the other hand, RPs could provide recovery options much like the password recovery schemes in use today.

I've had thoughts about that kind of standardised key management protocol as well, but I'd say that's well outside the scope of the initial ("Level 1") release of the WebAuthn spec. It might be possible to add that later in a way that would be somewhat compatible with existing registrations, but I'm skeptical about the feasibility of it. For starters, the website domains you register with aren't saved in (or even exposed to) the authenticator - in fact some authenticators won't actually store anything at all, and instead encrypt the data and "store" it in the credential ID on the server - so you'd need to maintain a separate list of domains for the management client to connect to. Couple that with how every RP will have their own unique quirks in how they manage accounts and registrations, and I don't foresee such a protocol being widely adopted even if one exists.

EDIT: My mistake, the authenticator does get the RP ID and might store it - but the issue of authenticators with no internal storage remains.

Anyway, this issue tracker isn't the place for extended discussion of this kind; see #820 (comment) :

If you want to have a general discussion about the specification and its goals, it should happen on the [email protected] mailing list.

[Kieun]

Account recovery and fallback scheme is not the scope of WebAuthN. But, there are couple of works to resolve such issues. FIDO D@S (Deployment at Scale) WG is intended to write some white papers in order to help RPs to handle such case securely and efficiently.

[selfissued]

This seems to be out of scope for WebAuthn.

[selfissued]

Closing, per 11-Apr-18 call.

[Oba-One]

Is this relevant or been solved know in 2022?

[emlun]

I would say this issue is superseded by #1695, #1663 and #1425.