What does HackerNews think of webauthn-recovery-extension?

Here [1] is Yubico's draft WebAuthn recovery ("backup authenticator") extension spec, which is possibly what you're thinking of.

[1] https://github.com/Yubico/webauthn-recovery-extension

> I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc?

An agent that registers non-discoverable credentials as discoverable ones via local storage is an option, although not one that browsers have yet chosen to support.

This however locks you onto a browser (if it doesn't have a cloud sync fabric) or into a particular ecosystem (if that browser has a sync fabric). Authenticators support discoverability because a limitation of only being able to authenticate in a single browser is significant.

Since authenticators tend to either support both discoverability and user verification, or neither discoverability nor user verification, I suspect there won't be business drivers to support such user agent storage/functionality.

Note that the CredProtect extension protects discoverability of a resident credential without user verification, and Chrome requests this extension on sites' behalf by default. This protects against scenarios where a third party who gets physical access to your authenticator (thief, partner, law enforcement, border control) can introspect the websites you have accounts at without your participation.

> Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard.

There was a serious proposal: https://github.com/Yubico/webauthn-recovery-extension

The challenge is that support for such things (new multisig algorithms, this recovery extension) require active relying party participation, and many would just choose not to take on the extra effort.

So instead we have multi-device credentials, where there is a sync fabric behind the scenes. Nothing would preclude hardware credentials from participating in such a thing, although they would obviously need either radios or software assistance to do so.

To capture the change in physical hardware, a new extension (devicePubKey) is being proposed under Web Authentication. This would have the benefit over the previous recoverability proposal in that sites opt-in to extra responsibility as needed for their business logic, compared to usability being restricted unless sites do extra work.

> Your idea is not very different from this proposed spec also defined by Yubico: 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.

Exporting is purposefully made impossible in many implementations of Passkeys (aka Webauthn authenticators) other than Apple's. For example, Yubikeys are designed so private keys can never leave the authenticator [0]. Enabling the export of private keys from an authenticator greatly increases the attack surface of an authenticator.

This is a long-standing security/usability tradeoff in the Webauthn spec. Various solutions have been proposed, but as far as I know most of them are still just drafts, e.g. [1]. The best practice has been and, as far as I know, continues to be to register multiple authenticators, e.g. a primary and a backup authenticator. This practice has a variety of benefits:

1. Avoids lockout if an authenticator is lost.

2. If you use multiple authenticators from different vendors (e.g. Yubico and Google) you:

1. Avoid vendor lock-in

2. Can rapidly respond in case a security vulnerability is discovered in one of your authenticators, as has occurred for both Yubico [2] and Google [3].

One could use Apple's Passkeys as one's day-to-day "personal" authenticator, and use an authenticator from a different vendor (e.g. Yubico Yubikey or Google Titan Security Key) as their backup key. I don't see how Apple's implementation increases the risk of lock-in beyond that of any of the other major Webauthn authenticator providers.

[0]: https://github.com/w3c/webauthn/issues/865#issuecomment-3804...

[1]: https://github.com/Yubico/webauthn-recovery-extension

[2]: https://www.yubico.com/support/issue-rating-system/security-...

[3]: https://security.googleblog.com/2019/05/titan-keys-update.ht...

There are some software tokens (Wear OS watch, Android phone), but they are purposely not exportable from the Android Keystore.

https://github.com/herrjemand/awesome-webauthn#software-auth...

There was mention of a secure backup proposal, but it doesn't appear to have been touched after being a draft for a year:

https://github.com/Yubico/webauthn-recovery-extension