Skip to content
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

githubs u2f appid changed #474

Open
NickeZ opened this issue Apr 27, 2020 · 12 comments
Open

githubs u2f appid changed #474

NickeZ opened this issue Apr 27, 2020 · 12 comments

Comments

@NickeZ
Copy link
Collaborator

NickeZ commented Apr 27, 2020

I saw this PR: #472 and remembered that I've noticed that githubs appid changed. Not sure exactly when. IIRC it is just sha256('github.com') now.

@NickeZ
Copy link
Collaborator Author

NickeZ commented Apr 27, 2020

python3 -c 'import hashlib; print(hashlib.sha256("github.com".encode("utf-8")).hexdigest())'
3aeb002460381c6f258e8395d3026f571f0d9a76488dcd837639b13aed316560

@NickeZ
Copy link
Collaborator Author

NickeZ commented Apr 27, 2020

btw I saw some discussion in the other PR regarding fido2 not using facets (urls) any more. That seems to be the case so that companies that use multiple domains can reuse the registration for all domains.

https://groups.google.com/a/fidoalliance.org/forum/#!msg/fido-dev/zP7XTnEywB4/uLN68lQdBwAJ

https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Migrating_from_U2F.html

@x1ddos
Copy link
Contributor

x1ddos commented Apr 27, 2020

Very useful! That image on https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Migrating_from_U2F.html tells me it was probably a good decision to not include facebook.comin #472?

fido2_u2f_migrate

Instead, we would need to recognize WebAuthn apps and prepend https:// to it. Ideally though, #473 is the way to imho. If we just allow hash(github.com) or hash(facebook.com), how would web origin be enforced in U2F world?

@NickeZ
Copy link
Collaborator Author

NickeZ commented Apr 27, 2020

Very useful! That image on https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Migrating_from_U2F.html tells me it was probably a good decision to not include facebook.comin #472?

If I try to register with facebook right now I get 3119... on my bitbox02:

niklasclaesson@ubuntu:~$ echo -n "facebook.com" | sha256sum
31193328f8e21dfb6c99f322d22d7b0b508778e64ffbba86e52293379031b874

So it seems to me that if you use a modern enough browser that has webauthn support both github and facebook has skipped the comp. layer and gone with the new standard.

It could be that they provide the appId if you registered the u2f-key with them before they switched to webauthn (they would need to tag every new registered device if it is registered using u2f api or webauthn api.)

All-in-all I think the bb02 will have to have both. The old one for people who registered with services before webauthn and the new one for everyone else.

Instead, we would need to recognize WebAuthn apps and prepend https:// to it. Ideally though, #473 is the way to imho. If we just allow hash(github.com) or hash(facebook.com), how would web origin be enforced in U2F world?

Only the browser could do that. The bb02 only gets the hash. I think this would be an accurate description:

# old (and also the case if github "knows" that your key is registered with this scheme)
GitHub JS -> U2F API -> BB02
# new
Github JS -> WebAuthN API -> U2F API emulator -> BB02

@jengo9332
Copy link

jengo9332 commented Apr 28, 2020

When I register the bb02 with github I get the "new hash":
3aeb002460381c6f258e8395d3026f571f0d9a76488dcd837639b13aed316560

If I understood this correctly, people who have already registered with github long time ago will receive the "old" hash?

@NickeZ
In terms of security would it matter if bb02 added both of the hashes even though FIDO2 isn't implemented yet?

@NickeZ
Copy link
Collaborator Author

NickeZ commented Apr 29, 2020

@NickeZ
In terms of security would it matter if bb02 added both of the hashes even though FIDO2 isn't implemented yet?

AFAIU we can add both yes.

@NickeZ
Copy link
Collaborator Author

NickeZ commented Apr 29, 2020

I think the new IDs are called Relaying Party ID or RPID. So I think the code should distinguish if it is an RPID or an AppID.

@x1ddos
Copy link
Contributor

x1ddos commented Apr 29, 2020

Instead, we would need to recognize WebAuthn apps and prepend https:// to it. Ideally though, #473 is the way to imho. If we just allow hash(github.com) or hash(facebook.com), how would web origin be enforced in U2F world?

Only the browser could do that. The bb02 only gets the hash.

Exactly. And that's what worried me. So, I grabbed a U2F demo and changed this line to:

const appId = 'github.com'

I then tried it on localhost over both http and https in chromium and firefox. Obviously, http didn't work at all because the API is enabled only on https, and on https both browsers replied with an "Error Code 2 Bad Request" for that appId. I guess they've implemented safeguards. Well, it's kind of expected, isn't it. :)

I also tried setting RP ID and AppID to github.com on https://webauthn.bin.coffee. Nothing worked, of course. Although, I didn't really expect any other result.

So, I don't see any security issues. Only some potential migration troubles for existing users on github and others which implemented WebAuthn with U2F extension.

@NickeZ
Copy link
Collaborator Author

NickeZ commented Apr 29, 2020

I don't know why they removed the schema from the ID. Fortunately it still looks like they only allow a subdomain of the RPID given. https://www.w3.org/TR/webauthn/#relying-party-identifier

I think the bb02 firmware should have two structs, one with appids and one with rpids. Then for u2f you search both and for fido2/passwordless/loginless you only search rpids. Does that sound reasonable?

@x1ddos
Copy link
Contributor

x1ddos commented Apr 29, 2020

I think the bb02 firmware should have two structs, one with appids and one with rpids. Then for u2f you search both and for fido2/passwordless/loginless you only search rpids. Does that sound reasonable?

Yes! but what about FIDO2 + U2F extension? esp. for existing users who already tied their bitbox to an account using U2F which is now FIDO2, like github.

@NickeZ
Copy link
Collaborator Author

NickeZ commented Apr 29, 2020

I think it is up to GitHub to implement the portability and show the appid in case you registered when they used appid. Since they have to store the keyhandle they could also store the creation date or some metadata that allows them to present the right ID to the bb02

@jengo9332
Copy link

I think the bb02 firmware should have two structs, one with appids and one with rpids. Then for u2f you search both and for fido2/passwordless/loginless you only search rpids. Does that sound reasonable?

Since the BB02 only receives the hash wouldn't it be sufficient to just append more entries to the list we have atm and just distinguish them by stating type (AppID/RPID)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants