githubs u2f appid changed about bitbox02-firmware HOT 12 OPEN

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

from bitbox02-firmware.

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

from bitbox02-firmware.

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?

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?

from bitbox02-firmware.

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

from bitbox02-firmware.

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?

from bitbox02-firmware.

@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.

from bitbox02-firmware.

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.

from bitbox02-firmware.

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.

from bitbox02-firmware.

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?

from bitbox02-firmware.

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.

from bitbox02-firmware.

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

from bitbox02-firmware.

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)?

from bitbox02-firmware.