-
-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getAssertion is not properly checking RP_ID in request against authentication mechanism in key handle. #306
Comments
so Let me get this straight: On a Normal Device you register it on, say google.com and it gets a now another site comes and requests signatures for "1234" (which certainly may be completely valid from a different device) and since (at least according to the nice infographic yubico made, the appid/RP-ID should fly into the final keypair together with the credential-id in unlimited mode the key should not be able to create a valid keypair and thereby just say "that's not a site I know", aka Error 4 from U2F. on Solo on the other Hand asking for that 1234 that it registered on another site, it apparently didn't let in the RP-ID into the generation and so does not create that error but instead just happily sign it? now THAT sounds like fun. I honestly don't know what is all the stuff that is inside the signature, if the RP data is inside there shouldn't be any security implications because even if you can relay a challenge and get a signature on another site, you won't be able to use it somewhere else if that site properly checks that the RP-ID actually fits, if not, it would be ugly. BUT one other pretty "fun" problem is a privacy implication. sites that work together could purposely exchange data and just try to mix some credential-IDs of the other RPs in to basically bind the profiles of those sites together allowing easier cross tracking since a profile link can be established considering I have a nice little mysql backed Webauthn sandbox as well as one for U2F I can try some stuff about all of this if you want. |
I accidentally discovered that getAssertion is not properly checking RP_ID in a request against the authentication mechanism in the key handle by sending the wrong RP_ID to the key in a getAssertion and having the key accept it. Other authenticators reject such broken requests.
It seems wrong that any RP can request assertions on another RP's credential ID. I'm not sure how bad this is, but my instincts say this might have security implications.
The text was updated successfully, but these errors were encountered: