- From: Rolf Lindemann via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Sep 2017 18:35:49 +0000
- To: public-webauthn@w3.org
One comment on https://github.com/w3c/webauthn/pull/539#issuecomment-326831893: I sense agreement on the following (and please correct me if you disagree): The signature counter provides a signal. 1) If the RP gets a signature counter mismatch (i.e. meaning counter value in assertion is equal or smaller to the one on file and the one on file is non-zero), then there is something badly wrong with the Authenticator. The RP doesn't know whether that authentication event leading to the mismatch was triggered by the legitimate Authenticator/User or the cloned Authenticator/attacker. But the trust in the authenticator should be reduced. 2) If the RP get's a counter match, the the RP don't know. It could still be something wrong with the authenticator (but the attacker was lucky to guess an acceptable counter value) or it was a legitimate authentication. Putting hardware failures aside for a moment, I see the signal being strong when a mismatch is signalled. It is unfortunately not "sharp", i.e. not seeing such mismatch isn't a guarantee for a valid authentication. Also the noise is being added in only one direction - making the signal less "sharp", meaning if the attacker increments the counter in the clone, it might be a legitimate authentication flagging a mismatch. Now back to the hardware issue. We have authenticators implement in tokens (with the flash issues) and we have authenticators implemented in TEEs and the like and authenticator implemented in Rich-OS level Software. The difficulty to create a cloned authenticator depends on the authenticator implementation. Especially the ones not prone to flash memory errors benefit from the couter the most. We already have the counter an optional element, so vendors concerned about flash lifetime or reliability can set the counter value in the assertion to 0 - flagging an unsupported counter. But other authenticator vendors could implement and use it - even with an RP specific counter since memory is less of an issue in the case of TEE or Rich-OS based authenticators. So I think there is value to keep it. -- GitHub Notification of comment by rlin1 Please view or discuss this issue at https://github.com/w3c/webauthn/pull/539#issuecomment-327575050 using your GitHub account
Received on Wednesday, 6 September 2017 18:35:48 UTC