Closed crrodriguez closed 7 years ago
I just received mine from Amazon and am having a similar issue as well:
Added 5 accounts to the device:
As of now, two of the Google account keys have vaporized and no longer work after adding the GitHub and Dropbox account. Any guidance for troubleshooting would be appreciated. Thanks!
@bmkillian the key that stopped working in my case was the github one.. maybe one of this sites is creating duplicates quickly and filling the device up.
@crrodriguez - based on what you've said, I've started troubleshooting to see if the GitHub key is also my issue. It is. I can fill the key with multiple Google and Dropbox accounts just fine, but the second I register GitHub, I lose the majority of my keys. The glaring exception is the first Google key I registered on the key did remain.
@crrodriguez @bmkillian thanks for sharing the issue and troubleshooting. I just started debugging and will report back soon.
@conorpp - Excellent. Thank you. Let me know if you need me to do anything else to help troubleshoot.
I've looked at Google and Github registrations closely. Sometimes when U2F Zero registers successfully, Google or Github will not acknowledge the response and will be stuck in "Register your key" mode. So if you register and the token goes Orange->light blue->green and Github or Google GUI has done nothing, then a key slot was wasted. It won't be able to be used to authenticate later. @crrodriguez, could this be why?
As to why u2f zero responses occasionally get ignored, I think it could be one of two reasons:
I recommend making sure the token has good contact in the USB port and by pushing the button you aren't disconnecting it or something.
I haven't been able to replicate registrations vaporizing. Even when the token fills up, it will not overwrite previous keys. I tried registering with multiple Google accounts and then Github and was still able to authenticate to everything, even after filling up all key slots.
@bmkillian, by vaporized, do you mean an account won't be able to authenticate with a previously registered token, even after trying multiple times? You aren't wiping them with the script in-between registrations, right?
@conorpp - Here's the process that seems to yield the problem:
At this point, I can authenticate with all of the above accounts with no problem. All of them work consistently
At this point, the following happens:
Now, if I wipe the token with the client.py util, I'm able to re-register the token with any of the accounts until I add GitHub back. That's when things go awry and I can't authenticate into the accounts. I can repeat the results of this consistently, so it doesn't appear that a weak USB connection is at stake. Hope this makes sense. Thanks!
I had a similar issue incoming GitHub and GitHub enterprise. Registering the first wipes the 2nd.
Just noticed something -- if you try to authenticate a key to a service it wasn't registered to on Chrome, it will send register requests after getting denied, without any notice. So it looks like it's authenticating but it's actually making useless registrations... this is likely a bug in Chrome's U2F API or the same services are using the same library.
Here is a HID USB packet trace that other developers could use:
// Client requests CID
ffffffff8600086ea1814dff2d31d900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
// Token assigns CID cafebabe
ffffffff8600116ea1814dff2d31d9cafebabe020200000300000000000000000000000000000000000000000000000000000000000000000000000000000000
// Client requests U2F version
cafebabe830007000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
// Token replies U2F_V2
cafebabe8300085532465f5632900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
// Client sends auth request
cafebabe83004e00020300000045c5a499a098adc962ac122727366e98fb5f6fd6cad8b69127733354ae03447058a54672b222c4cf95e151ed8d4d3c767a6cc3
cafebabe0049435943794e884f3d023a8229fd0404b1361b00000000000000000000000000000000000000000000000000000000000000000000000000000000
// Token replies U2F_SW_WRONG_PAYLOAD (denied, wrong key handle)
cafebabe8300026a8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
// Now client sends perfectly valid registration request, leading to bad registrations because user thinks it is an auth request
cafebabe830049000103000000404242424242424242424242424242424242424242424242424242424242424242414141414141414141414141414141414141
cafebabe004141414141414141414141414141000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
@bmkillian when it fails to authenticate, does it report an error, or just seem to do nothing? Does the key still turn orange and then light blue -> green when pressing button?
The website indicates the key isn’t registered. Unfortunately, I don’t recall the LED indications, but I’ll repeat the process and take note.
From: Conor Patrick [mailto:notifications@github.com] Sent: Saturday, November 12, 2016 9:24 PM To: conorpp/u2f-zero Cc: Brandon; Mention Subject: Re: [conorpp/u2f-zero] usage problem with multiple sites (#36)
@bmkillian https://github.com/bmkillian when it fails to authenticate, does it report an error, or just seem to do nothing? Does the key still turn orange and then light blue -> green when pressing button?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/conorpp/u2f-zero/issues/36#issuecomment-260164496, or mute the thread https://github.com/notifications/unsubscribe-auth/AL7kdfOGl4DH46whjXpXxGiiPq01yKYVks5q9oLGgaJpZM4KtEP_ .
The phantom registration behavior from chrome is pretty weird.
But I'm puzzled as to why this would do anything bad. Don't you need to press the button in order for it to actually perform a registration? Perhaps you should require that the button not be held down before a command is issued, requiring for the press to happen after the command is issued.
@darconeous Yes the button still needs to be pressed, it's just that the user might press the button anyways in attempt to authenticate
Added just added support for on the fly key derivation so there is no longer a limit on key storage. I think this should solve any issues with multiple sites and unsolicited register requests.
If anyone wants a new token please send me an email with your mailing address.
Hi:
I hope someone can figure this out..
I registered the key on:
This works fine...for a while After that I cannot register new services at all..and the key appears to get "full".. only a key wipe can restore functionality. I am aware there is a 15 key limit.. but I count only 5 registrations so far (it happended with just 4 too) can a website be buggy and fill the device with key rthat it ends not using at all ?
How do I know how many slots are used up for example ?