New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 813014 link

Starred by 1 user
Status: WontFix
Owner:
█ hongjunchoi@chromium.org
Last visit > 30 days ago
Closed: Feb 2018
Cc:
reillyg@chromium.org
kpaulhamus@chromium.org
█ piperc@chromium.org
jdoerrie@chromium.org
kenrb@chromium.org
martinkr@google.com
engedy@chromium.org
ssoneff@google.com
mknowles@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

[webauthn] U2fRegister should only prevent duplicate registration on a single device

Project Member Reported by jdoerrie@chromium.org, Feb 16 2018 
https://crrev.com/c/739927 introduced logic to prevent duplicate registrations (i.e. support for excludeList), but it will check *all* devices for duplicates before attempting to register a new credential. This behavior potentially prevents adding a second security key for the same account, which is not what the WebAuthN spec intends [1]:

"""
This member is intended for use by Relying Parties that wish to limit the creation of multiple credentials for the same account on a **single** authenticator. [...]
"""

[1] https://www.w3.org/TR/webauthn/#dom-makepublickeycredentialoptions-excludecredentials

Comment 1 by hongjunchoi@chromium.org, Feb 16 2018

Cc: kpaulhamus@chromium.org jdoerrie@chromium.org
It is true that logic in https://crrev.com/c/739927 introduces checking *all* devices for duplicate keys. However, OPERATION_NOT_ALLOWED is only sent to the relying party if the end user touches a device with duplicate registration keys. 

Therefore, even in the case where there a token with duplicate registration key and a new token without any registration key are both connected, this would not prevent registration with new token because callback with OPERATION_NOT_ALLOWED with only be triggered after verifying user touch. 

The precise behavior has been added as a unit test in https://cs.chromium.org/chromium/src/device/fido/u2f_register_unittest.cc?l=489 . Please let me know if you think this is still potentially problematic!

Comment 2 by engedy@chromium.org, Feb 19 2018

Status: WontFix (was: Assigned)
Thanks, turns out this was a misunderstanding.

We thought that CONDITIONS_NOT_SATISFIED would not be returned until after a certain U2fDevice times out (waiting for touch), but looks like the error is returned < 500 ms if the device has not been touched yet, so that we are going through all the devices in a round-robin fashion.
►

Sign in to add a comment