search

Firehed / u2f-php

An implementation of the FIDO U2F server protocol in PHP
MIT License
73 stars 9 forks source link

Add support for new WebAuthn #2

Closed Firehed closed 3 years ago

Firehed commented 6 years ago

https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-javascript-api-v1.2-ps-20170411.html

Background This section is non-normative. CHANGES: This version version 1.1 of the FIDO U2F JavaScript API specification supersedes version JavaScript API 1.0. The major difference between these two versions is the way that requests to be signed are formatted between the RP and the client: In version 1.0, a separate appId and challenge were sent for every keyHandle, whereas in version 1.1, an optimization is made that requires only a single appId and challenge for multiple keyHandles.

LOW-LEVEL API: Although this specification refers to two separate API levels, we want to discourage a Relying Party (RP) from implementing directly against the Low-level MessagePort API as this may be deprecated in future versions of this specification. RPs should rather implement against the High-level JavaScript API and use a library that abstracts the lower-level MessagePort API if required.

madwizard-thomas commented 6 years ago

Any plans to support the new webauth standard as well?

Firehed commented 6 years ago

I'm not familiar with it yet, but quickly skimming over the W3C document I found it looks like it won't be a huge stretch to support once it's finalized.

Seems like it's mostly some adjustments to message formats, as far as the server-side stuff is concerned (in fact, I wouldn't be surprised if compatibility could be achieved purely client-side by adjusting the data before it's sent to the server).

I'd ideally like to see a reference implementation as well, but it's probably not strictly necessary. At the very least, it seems prudent to hold off trying to get this working until the spec reaches Recommendation status, in case there are any format changes. Also given that it's likely to require data parser adjustments, it's probably best to address #4 first so that it's easier to swap in/out components as needed.

madwizard-thomas commented 6 years ago

I've read it through as well and it seems to be similar but includes some more functionality (such as requiring a name and unqiue id for the user and a challenge nonce for the registration) and more attestation formats. This allows for storing user account in the credential store (for management and to prevent multiple credentials for the same user for the same website), but most hardware devices probably will not support this since they don't actually store anything (this is allowed as well by the standard).

Since the standard comes from earlier U2F versions it will likely be similar. I think the attestation may have a different structure. Another problem is that the objects passed to the registration and signing function contain ArrayBuffers now so they can't be parsed directly from server side JSON but will need some client side processing.

It might also be that Firefox will have webauthn on by default but not u2f if I read the Mozilla wiki ("Goal: permit use of U2F tokens via a user-controllable preference (not on by default) in Firefox 56 or 57 (Done in Firefox 57), and Web Authentication (on by default) in Firefox 59 or 60. "). You're right that the standard is not finished yet but I think it's pretty close and webauthn will likely replace u2f in the future.

Firehed commented 6 years ago

Update on this:

At this point, it appears the standard is finalized (w3.org labels it as candidate recommendation).

Using that spec, I've managed to get a working POC on the client side that validates the registration and login data by directly calling the openssl functions (i.e. not actually integrated with this library).

There are some small incompatibilities in the way the "data being signed" is composed in the library, but comparing the two side-by-side they're more similar than they are different. It might even be possible to implement the necessary changes in a non-breaking way (the RegisterResponse and SignResponse should have a getSignedData method that does what's currently done in the Server). I think the rest boils down to determining the shape of the data over the wire for the fromJson methods, and adding a client lib for the ArrayBuffer stuff and turning the browser-native credential objects into compatible json.

None of what I've looked at so far is super comprehensive, but it looks promising. No concrete implementation details or timeline. The only sticky point I've come across is that the only CBOR decoder I came across doesn't have a stable tagged version; functionally it appears fine but it makes distribution a bit problematic.