[webauthn] Prevent browsers from deleting server-side credentials for the RP (#1569)

lgarron has just created a new issue for https://github.com/w3c/webauthn:

== Prevent browsers from deleting server-side credentials for the RP ==
At the moment, Safari and Windows Hello create discoverable credentials even if the RP does not specify `residentKey` or `requireResidentKey` criteria. This somewhat makes sense, since there is no way for the RP disallow discoverable credentials — only "discourage".

However, this means that Safari and Windows Hello overwrite any existing credential for a given [RP, user handle] pair when a new one is created. This is allowed, per:

> Note that a discoverable credential capable authenticator MAY support both storage strategies. In this case, the authenticator MAY at its discretion use different storage strategies for different credentials, though subject to the residentKey or requireResidentKey options of create().
https://w3c.github.io/webauthn/#sctn-credential-storage-modality

This present a problem for sites that want to implement passwordless/usernameless flows, but have  existing "security key" registrations. Many such sites will have users with "security key" registrationsthat are backed by platform authenticators through  Windows Hello or Safari: the RP cannot create a new registration without the risk of silently invalidating old registration. This can potentially lock out users — especially security-conscious users who make sure that their only two-factor options are security keys.

The RP can include all security keys in `excludeCredentials` when calling `create` for a passwordless/usernameless registration, but the only safe way to do this is:

- Prompt for a new registration with security keys in the exclude list.
- If there was a potential existing registration (which is not straightforward; see #1566), prompt the user to authenticate so the site can tell which security key.
- Prompt for a new registration with the given security key excluded, then delete the old security key registration with the new registration.

In addition to being cumbersome and confusing:
- If the new registration does not have a superset of the functionality of security keys, the user may need to make an uncomfortable choice and potentially put themselves at higher risk of lockout. This would be the case for passwordless registrations that are purely tied to cookies, as advocated by [Safari](https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/) and [Google's contributions to HowToFIDO](https://github.com/fido-alliance/how-to-fido/blob/master/HowToFIDO.md).
- If the flow fails in the middle, it can be confusing to explain what happened, and the RP might need to make the user jump through even more hoops.

Windows and Safari might change their implementations, but this is a non-obvious trap for browsers and RPs that can lock out users — and we discovered it at GitHub only after months of working on WebAuthn. I think it would be best for RPs and users if the spec could help make sure that old security key registrations are never overwritten by accident.

One option would be to replace "MAY" with "MUST" in the section I quoted above, but I don't know if that would help with legacy registrations that are out there in the wild today.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1569 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 9 February 2021 04:13:31 UTC