Closed Bug 1409532 Opened 7 years ago Closed 1 year ago

u2f.register fails with registeredKeys array

Categories

(Core :: DOM: Web Authentication, defect, P5)

58 Branch
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: u424271, Unassigned)

Details

(Whiteboard: [webauthn] [webauthn-interop][u2f])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171017141229

Steps to reproduce:

1. Register a U2F device, (empty array as `registeredDevices` parameter)
2. Post U2F registration data to my server. Process using Yubico PHP U2F library, and return keyHandle
3. Register a U2F device, (`registeredDevices` array with one object)

```javascript
var challenge = new Uint8Array(16);
window.crypto.getRandomValues(challenge);
var regRequest = {version: "U2F_V2",challenge: btoa(challenge)};

var appId = window.location.origin;
console.log(regRequest);

//Use empty array first time
registeredDevices = [];

u2f.register(appId, [regRequest], registeredDevices, function(regResponse) {
  console.log(regResponse);
});
```

```javascript
registeredDevices = [{appId: appId ,keyHandle: "FbA-6kv5tuVU07XvSObRogJGQBgAnQ663NIWAiIXjgrxRXsNXLobj5kTWh_1aA2zNv25TbPytFyU_WoIkppomVI6uHwFEFLdfiKyW4YkuLQ",version: "U2F_V2"}];
```


Actual results:

Light on U2F key did not flash. After about 30s, error code 1 (OTHER_ERROR) shown in console

If the returned keyHandle is changed, the light will flash and the U2F key will return registration data


Expected results:

Light on U2F key should have flashed

u2f.register should have returned error code 4 (DEVICE_INELIGIBLE)
Deferring the triage to :jcj :)
Flags: needinfo?(jjones)
Thanks for the report. Since Tim is doing most of the state machine work now, I'm going to refer this to him.

We hadn't built the registration state machine to cause devices to blink when they have the key. I don't believe that's in the specification, but perhaps Chrome does it? (Can't check right now)

That said, returning DEVICE_INELIGIBLE is in the spec, and would affect Web Authentication, too, I think.
Flags: needinfo?(jjones) → needinfo?(ttaubert)
(FWIW, I've just been marking U2F/WebAuthn-related bugs as P2 since I know the team wants to ship in the next few months. Please tell me if that's wrong.)
Priority: -- → P2
Reproduced at FastMail: adding a U2F token that is already registered produces DEVICE_INELIGIBLE in Chrome as expected (leading to an appropriate “This security key is already registered” message), but does nothing and eventually produces OTHER_ERROR in Firefox (leading to a generic “Sorry, something has gone wrong” message).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
Whiteboard: [webauthn] [webauthn-interop][u2f]
We double-checked with the spec and we believe that Chrome's behavior is closer to the U2F spec they implemented first. Firefox implements what WebAuthn states:

One should iterate over all available authenticators and try to create a credential with each of them, passing the list of already registered credentials to exclude. Now the implementation should:

> Check if any credential bound to this authenticator matches an item of
> excludeCredentialDescriptorList. A match occurs if a credential matches
> rpEntity.id and an excludeCredentialDescriptorList item’s excludeCredentialDescriptorList.id
> and excludeCredentialDescriptorList.type. If so, return an error code
> equivalent to "NotAllowedError" and terminate the operation.

The outer iterator must then:

> If any authenticator returns an error status,
> Remove authenticator from issuedRequests.

This means that Firefox waits until the specified timeout has passed. Other tokens might be inserted by the user at this point, but the already registered one can't be used for registration.

The UX as specified in the WebAuthn spec here is deliberate, otherwise a site could take a stolen credential and use that to potentially confirm the identity of a user, by passing a list of credentials in the exclude list.
Flags: needinfo?(ttaubert)
As a separate comment, so this isn't lost: we need to probably make the token blink, for privacy reasons. We're not sure yet what to do when the user hits the already registered token. Per spec, we should time out. An authenticator failure shouldn't affect the operation as a whole.
Hi, just to comment I've hit the bug yesterday aswell.

What is stated in the last comment is how Chrome does it.. the token blinks and when you tap it, it returns the error code 4, DEVICE_INELIGIBLE. If you don't tap it than it timeouts after some time with error code 5. I think that is a good solution.

Just waiting for the timeout seems bad as there is no feedback to the user... it looks like something is broken/bugged (thats what I thought for half an hour). With blinking + if the user taps he will get the message about the problem, and then he can try with another.

To me the wording above makes sense if for example you start out with 3 authenticators, then 2 have errors and are removed from issuedRequests and the last one can still be used so you wait for it. But if you start with 3 and all 3 have errors, then it should return immediately with an error.
Component: DOM: Device Interfaces → DOM: Web Authentication
Priority: P2 → P5
Severity: normal → S3

Closing as WONTFIX because the U2F API will be removed in the near future (Bug 1737205).

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.