- From: Rolf Lindemann via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Feb 2022 10:31:35 +0000
- To: public-webauthn@w3.org
Some additional considerations: 1. Security related and 2. adoption related **1. Security Related:** Both, extensions and the authenticator flags are signed by the key in question (that could potentially be backed-up and restored to a different authenticator instance - potentially with different security (e.g. key protection) characteristics. Following scenario: a) key/credential being generated in a very secure authenticator (e.g. secure element level key protection). Registration assertion truthfully reports multi-device capable, not backed up. b) first authentication happens and authentication assertion truthfully reports multi-device capable, not backed up. c) second authentication happens and authentication assertion truthfully reports multi-device capable, backed-up (now backup was performed) d) key is being restored in a much less secure authenticator (e.g. rich-OS SW level) and key was extracted by an attacker. e) attacker performs authentication and authentication assertion maliciously reports "not backed up" (and potentially even "single device". Since the attacker has access to private key in the clear, any extension/authenticator flags could be generated and signed. Note that in reality step b+c could even be omitted, making it more complex for the RP to determine the risk. For me it means that (from a security perspective), it is important (i) to have the option to request attestation and to have a description in the related MetadataStatement whether this authenticator supports multi-device keys in general or not and (ii) that the trust that an RP might have in the flags included in the registration assertion (i.e. attestation statement) would be "higher" than the trust in the extensions/flags in the authentication assertion (if the authenticator supports multi-device credentials). - Because of (d) + (e). (iii) to emphasize that seeing "single device" in an authentication assertion after having seen "multi-device/capable") in any assertion is an indication of increased risk (potential attack). (iv) the flag backed-up or not-backed-up is relevant for driving user experience (but very limited from a security perspective), i.e. don't think the key is more secure just because you haven't seen a "backed-up" indication in any assertion yet. **2. Adoption Related** The way we have architected extensions, requires FIDO Clients (e.g. Browsers) to actively "pass them through". Additional flags in the assertion on the other hand would be "passed through" by default. That means that the "flags" approach will work ubiquitously, while the extension approach might require changes (depending on the implementation approach in Browsers). -- GitHub Notification of comment by rlin1 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1692#issuecomment-1042800482 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 February 2022 10:31:38 UTC