- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Aug 2017 14:29:28 +0000
- To: public-webauthn@w3.org
@agl said in above comment: > I don't, personally, know the tradeoffs for an **authenticator nonce** but the last time I had an interaction with a representative from NXP they were very clear that such a thing was useful. > > But existing FIDO devices don't have such a field... Actually, FIDO UAF authenticators do have an authenticator nonce (search for TAG_AUTHENTICATOR_NONCE in [fido-uaf-authnr-cmds-v1.1-id-20170202.html](https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-authnr-cmds-v1.1-id-20170202.html#tag_uafv1_auth_assertion)), though U2F authenticators do not. > I understand that the theory of signature counters is that an attacker who obtained a private key would be forced to break the legitimate key by advancing the counter. Thus the user would be "informed" of the attack because their key would stop working. > But, in practice, that'll be surfaced as an opaque, unactionable error to the user, who will probably just be annoyed that the security key stopped working... not necessarily. it all depends on whether the RP is paying attention to the signature counter, and if so how they incorporate it into their risk calculations. Yes, a simplistic approach would be to cease to honor that user<-->RP key pair. A more nuanced approach will take other factors into account resulting in a smoother experience for users. > From the server's point of view this attack signal is very likely to be drowned out in the noise of tokens failing to do a flash write, corrupting their flash etc, and thus be useless there too. not necessarily. Perhaps so, for RPs who attempt to employ this signal in a simplistic fashion. RPs employing risk analysis will be able to factor in further information, such as, e.g., an allegedly-cloned user private key continuing to be used from the same user device in the same location as other allegedly cloned instances, and calculate this as more benign (within the overall risk calculation). > On the other hand, tokens are very likely to use a single counter for all sites because per-site counters require per-site storage in the token. Indeed, the token that I'm using at the moment has a single counter which is currently 1,838. The progression of that value is likely strongly identifying. yep, agreed there is a privacy consideration there and we should treat it appropriately in the spec. -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/pull/539#issuecomment-326313175 using your GitHub account
Received on Thursday, 31 August 2017 14:29:33 UTC