W3C home > Mailing lists > Public > public-webauthn@w3.org > May 2016

[webauthn] Security: Signature format doesn't cover whole context

From: Alexei Czeskis via GitHub <sysbot+gh@w3.org>
Date: Fri, 13 May 2016 09:46:35 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-154673808-1463132794-sysbot+gh@w3.org>
leshi has just created a new issue for 
https://github.com/w3c/webauthn:

== Security: Signature format doesn't cover whole context ==
The basic principle we should follow is that the Authenticator should 
sign over the entire context that is presented to it; this just a best
 practice. This allows the RP to verify exactly what the authenticator
 saw when it created a registration or assertion intended for the RP.

Currently, the signature produced by getAssertion does not sign over 
the RP ID seen by the authenticator.  **We should modify the signature
 format so that it also covers the RP ID.**

These concerns are purely theoretical.  For example, here is one 
possible consequence of not following best practices.  This is just an
 example, there may be other attacks that we haven't though of.

**Example**:
The TL;DR the attacker achieves in this attack is that a user with a 
compromised client device and a properly functioning authenticator is 
put in a situation where that authenticator will only work with the 
compromised client device (i.e., attack persistence). The external 
authenticator won't work with any normally functioning client (i.e, a 
denial of service on any un-compromised client). So the user will have
 an incentive to keep using the compromised client device, because 
their external authenticator "doesn't work with anything else".

Details: The user registers their good external authenticator on 
Bank.com using this compromised client device. During the registration
 (and in all subsequent sign-ins) the attacker changes the RPID being 
sent to the external authenticator from Bank.com to Changed-Bank.com. 
The registration happens correctly as far as the user and Bank.com are
 concerned. After registering, the user is able to log-in to Bank.com 
on this compromised client device, since the change of RPID is 
consistent.

However, if the user now takes that authenticator to a normally 
functioning client device, he/she cannot login to Bank.com. The 
Credential ID sent by bank.com does not match the RPID for Bank.com 
and so the authenticator silently refuses to sign. The user sees it as
 "My token doesn't work with this device"

If the authenticator also signed over the RPID that it saw, the above 
attack would not work. At registration time and with assertions, 
Bank.com would realize that the external authenticator saw something 
saw some RPID other than Bank.com.


**There are likely more attack examples**

Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/107 using your GitHub account
Received on Friday, 13 May 2016 09:46:38 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:20 UTC