Closed zachreizner closed 7 years ago
Good point to bring up.
U2F prohibits having any identifiers for privacy reasons so that makes it tricky to delete individual services. One idea I had was to have an option to delete the last service you authenticated to.
I decided it was not worth to implement because:
If you or someone wants to make a pull request with a good, low complexity solution, I will accept.
I'll make the 15 slot limit more prominent.
I'm running into an issue with a key I was experimenting with and have started using. I can register with github.com and a github enterprise instance at work, but then the github.com registration becomes invalid. I've done troubleshooting with github and they said everything looks ok in our instance database and on their end. Does the 15 limit and the inability to delete services seem like a reason as to why this would happen?
Okay to make sure I get this right:
I don't think it's an issue with 15 keys as registering a 16th service would just fail and not overwrite over services.
It may be an issue with appid and keyid. The appid is a static hash of the domain being authenticated. The keyid is the identifier for the key. The server supplies both of these when authenticating, and the token uses the keyid to look up the key and it's copy of the appid received during registration. It checks that the supplied appid and stored appid are the same. Then it proceeds to authenticate.
Do you know if the keyid for both Github records is different? What about the appid?
I do know what the enterprise version does, but I'm not sure what the github.com version does. I have a support ticket open and I'm going to try and get them to engage on this subject with us. I can also paste in my token info that I got from github enterprise because I've already deleted the key.
This is the trusted facets info from our enterprise instance:
{"trustedFacets":[{"version":{"major":1,"minor":0},"ids":["https://github.private.corp.com"]}]}
This is github.com:
https://github.com/u2f/trusted_facets
{"trustedFacets":[{"version":{"major":1,"minor":0},"ids":["https://github.com","https://garage.github.com","https://machine-room.github.com","https://spider-skull-island.github.com","https://admin.github.com"]}]}
This is the output from their database I've shared with their support:
[#<U2fRegistration id: 4, user_id: 3, key_handle: "CBzkgQ", certificate: "MIIB0jCCATcCAQEwCgYIKoZIzj0EAwIwczELMAkGA1UEBhMCVVM...", public_key: "BGH8JfYExfhdB7aSGVtpuytEoaF/YpPjR2W4q/mybi93VjcT0pm...", counter: 11, nickname: "u2f zero personal", created_at: "2016-10-12 18:29:33", updated_at: "2016-10-12 18:29:56">]
Github got back to me and to quote them:
Thanks for the update and posting an issue in the u2f-zero repository. It looks like you have been able to provide the information that conorpp has requested so far.
I can confirm that both the AppID and key handle are unique per GitHub instance, with GitHub.com and your GitHub Enterprise appliance using different values.
Please let us know if there is any further information we can provide that would be helpful for conorpp's ongoing investigation.
Awesome, thanks for the info and confirmation. I will find some time over the next few days and try to reproduce.
This issue is succeeded by https://github.com/conorpp/u2f-zero/issues/36
If I run out of space, I have to reregister every server just to make room. Not a problem right now, but I have 2 or 3 registrations I made just to test out the device. Also consider making the 15 slot limit more prominent. That fact, along with the wipe-only removal option, came as an unhappy surprise to me while digging through the wiki. Cool project though. I might buy another one just for testing.