Re: [w3ctag/design-reviews] Broadening the user base of WebAuthn (Issue #686)

> How safe are sync fabric providers?
> …
> Have you and the working group considered these types of scenarios? What sort of mitigations might be added to the spec or the ecosystem to protect users from scenarios like these?

Starting more broadly, I don't think a W3C spec has much (any?) influence here. I would think of it in the same way as password managers. There are several, and probably people have opinions about their relative security, but I don't think that HTML5 would achieve anything if it, say, mandated particular designs for password managers.

Similarly, Web Authentication currently defines an interface for using security keys and typically those are separate physical devices or embedded secure hardware. But one can also flip a switch in Chromium's DevTools and store credentials in software for testing. Web Authentication does not (and should not) prohibit that. (Although it does include support for attestation that can effectively prevent it in enterprise environments.)

Getting more specific, I can only speak about Google's potential sync system here. 

If Google were to build a sync system we would not wish to have access to the credential private keys. You can see [public information](https://research.nccgroup.com/wp-content/uploads/2020/07/Final_Public_Report_NCC_Group_Google_EncryptedBackup_2018-10-10_v1.0.pdf) about how Android Backup implements end-to-end encryption and thus how that might be achieved in this context.

(iOS and macOS can sync WebAuthn credentials via iCloud Keychain, behind a developer flag. You can find information about iCloud Keychain online.)

> Can you say more about device-key extension?

> Would you imagine those keys expiring regularly (monthly or weekly, etc)?

(Noting, again, that I can only speak about Google's potential implementation of this.)

We do not have a firm opinion on expiration of these keys. At one end, one could think of them like cookies and thus reset them whenever cookies for that domain would be removed. But they are a lot higher friction than cookies since WebAuthn credentials require biometric confirmation (at least with Google's current platform authenticators). So perhaps they are more like saved passwords, which persist. It seems likely that management UI would allow them to be reset, but there is not yet a firm answer on whether that would also happen automatically if Google were to launch support.

> how much damage could still be done if credentials were leaked before they expire? And are there other ways to protect users in this scenario?

We can consider a WebAuthn credential, in this model, to consist of either one or two private keys. The primary private key cannot be hardware bound since it is synced. The, optional, second private key (the device-bound key) hopefully would be hardware bound on a particular device. Thus the greatest risk is to the primary private key and the obvious way for an attacker to obtain them would be to impersonate the victim to their sync provider and know the victim's PIN/pattern.

The consequences of this are similar to when using a password manager: pretty bad. The attacker would have the user's credentials. Sites opting to additionally use a device-bound key would notice that a new device is being used but the protection afforded by this is up to the site. Similar to obtaining the complete set of a user's passwords, the remediation would be to rotate registered credentials on all sites.

User-agents may be able to [aid](https://blog.google/products/chrome/automated-password-changes/) in doing this should it be needed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/686#issuecomment-1027197167
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/686/1027197167@github.com>