cedarcode / webauthn-ruby Goto Github PK

https://www.w3.org/TR/webauthn/#android-key-attestation

https://www.w3.org/TR/webauthn/#dictionary-makecredentialoptions

In particular, the v1.0.0 link at the top of https://github.com/cedarcode/webauthn-ruby/blob/master/CHANGELOG.md doesn't work.

Currently we assume there is no Extension Data coming inside AuthenticatorData.

We should consider that a possibility and make the parsing smarter to account for that.

Helpful links:

• w3c/webauthn#1012

P-8 Send a valid ServerAuthenticatorAttestationResponse with SELF "packed" attestation, for "ALG_SIGN_RSASSA_PKCSV15_SHA1_RAW" algorithm, and check that the server succeeds

Needs support for RS1.

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

AuthenticatorAttestationResponse#valid? and AuthenticatorAssertionResponse#valid? accept origin as its argument, and these methods use it for both RP ID and client data origin validation.

But as you may know, RP ID may be different with origin:

• By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain. This default MAY be overridden by the caller
  https://www.w3.org/TR/2018/CR-webauthn-20180807/#rp-id

• Separating the origin from the RP ID in this way allows the API to be used in cases where a single Relying Party maintains multiple origins.
  https://www.w3.org/TR/2018/CR-webauthn-20180807/#api

Current interface doesn't allow RP implementation to validate RP ID which is not based on request origin.

Additionaly, unlike maintaining multiple origins for single RP ID, appid extension generates RP ID different from a request origin. If the extension has used in a assertion response, RP ID hash would be generated from https://origin instead of origin. This extension is commonly used for migration from legacy U2F API.

Interface to accept RP ID

I don't make PR now because I want to discuss the interface with you before starting implementation. My idea follows:

assertion.valid?(challenge, origin) # rp_id will be assumed to URI.parse(origin).host
assertion.valid?(challenge, origin, rp_id: 'custom-rp-id')

This interface is good because providing good default for most RP implementation, because RP ID is usually a host part of the origin URL.

WDYT?

F-1 Send ServerAuthenticatorAttestationResponse that is missing "id" field and check that the server returns an error

F-4 Send ServerAuthenticatorAttestationResponse that is missing "type" field and check that the server returns an error

MakeCredential Resp-1 tests are mostly about verifying PublicKeyCredential id and type properties when received by the server.

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

According to https://blog.chromium.org/2018/09/chrome-70-beta-shape-detection-web.html Chrome version 70 will support TouchID on recent Macbooks with a Touchbar, and the fingerprint scanner on Android devices. I have only access to the latter at the moment.

I've tried to use my Android device on https://webauthn.herokuapp.com/ but it didn't work. And for some reason after that initial attempt it doesn't show the fingerprint option anymore, on this demo site or the one from Google, which makes debugging hard.

Interestingly enough the Google demo does return "User verifying platform authenticator present" when clicking the "Check ISUVPAA" button on my Android device 🤔

https://www.w3.org/TR/webauthn/#tpm-attestation

Wouldn't be better for the gem to "just call verification and then return whatever the result was" instead of "returning nil (like saying I don't know)", in case #attestation_type is called before (or even without) calling valid? or verify?

We'll still match the spec. Just easing the ruby gem usage experience.

Originally posted by @grzuy in #122 (comment)

If user verification is required for this registration, verify that the User Verified bit of the flags in authData is set.

https://www.w3.org/TR/webauthn/#registering-a-new-credential

Related to #182

Started failing because of the certificate used in the test expired in December, causing validation to fail.

https://www.w3.org/TR/webauthn/#dictionary-makecredentialoptions

Candidate for a setting in the configuration, then possibly overwritten in each ceremony.

Thanks for working on a Ruby WebAuthn implementation. A well supported library will hopefully spur adoption for the many Ruby apps out there today.

I'm curious why you've chosen to use the msgpack based CBOR implementation instead of the libcbor implementation. Knowing very little about either, it seems like libcbor would be preferable. It seems like the msgpack implementation will be difficult to maintain as updates and security fixes are made to the upstream msgpack code. The cbor-ruby Gem has seen virtually no changes since 2016 while the msgpack-ruby Gem is under active development. This seems concerning. In comparison, the libcbor codebase seems more active and easier to maintain.

As I said, I know very little about either project, so the msgpack one might be way better. I'm mostly curious about the thinking behind your choice.

With webauthn-ruby being a security sensitive gem, it might be worth setting up a means for users/researchers to disclose security vulnerabilities that isn't through the public Github Issues interface. Examples can be found in rails, devise, ruby-saml.

The spec folder has a fake authenticator implementation. I've had trouble extracting that code and getting it working for testing our backend.
. (At themoment

Would it be possible to expose this fake authenticator for testing, with about the convenience of https://github.com/castle/ruby-u2f/blob/a525e7aad75f72ccd122b135b1b9676a427d5f68/lib/u2f/fake_u2f.rb ?

https://www.w3.org/TR/webauthn/#dictionary-makecredentialoptions

Also I think I would add a default of 120s.

I guess we can let this be set in the configuration, then optionally overwritten per ceremony.

User should be able to set

WebAuthn.configure do |config|
  config.timeout = 30
end

P-1 Send a valid ServerAuthenticatorAttestationResponse with "android-safetynet" attestation, and check that server succeeds

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

leaving this as an issue to note, this is not a requirement from me.

http://w3c.github.io/webauthn/#sctn-attestation-types

There several lines like the following in the attestation statement verification steps:

If successful, return implementation-specific values representing attestation type Basic, AttCA or uncertainty, and attestation trust path x5c.

Maybe returning attestation type from AttestationStatement::Base#valid? could be an interface?

I have no need for this, but I can imagine others will have this question at some point. I think it will be helpful to show how reg.key_handle and reg.public_key from the registration example at https://github.com/castle/ruby-u2f#registration can be used with this gem for migrating an existing U2F implementation.

Icing on the cake would be how to use the Webauthn FIDO AppID Extension as well if a U2F implementation uses an app ID with multiple facets.

We're currently in the process of adding support for other attestation formats than none and fido_u2f. I suggest we add a section to the README that states these formats upfront instead of having them browse the code to see which ones have support in the gem.

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

https://www.w3.org/TR/webauthn/#dictionary-makecredentialoptions

webauthn allows FIDO security keys to continue to work even if they were registered using U2F. However, if an old registration specified trusted facets using a JSON URL [1][2], webauthn requires using the old AppID URL as the RP ID, with an extension:

navigator.credentials.get({
  publicKey: {
    timeout: /* ... */,
    challenge: /* ... */,
    allowCredentials: /* ... */,
    extensions: {
      appid: "https://site.example/u2f/trusted-facet-list.json"
    }
  }
})

Sites that had significant U2F adoption will pretty much need to plan to handle this permanently. In order to use this library, we're need several modifications:

• credential_request_options should have a way to specify an appid.
• AuthenticatorAssertionResponse needs a way to know to use an appid as an RP ID, and use this for URL comparisons and verification of the RP ID hash of the authenticatorData.
• Many places that assume that the RP ID is an origin (e.g. docs, function parameters) will imply something incorrect in the general case. It would be preferable to keep this accurate, which might require renaming some places to rp_id or such.

Would you be willing to add support for this AppID use case?
If so, do you have any preferences about how to implement it? For example, would you prefer to handle this in AuthenticatorAssertionResponse itself, or in a subclass? Would you like it to be handled to extra parameters for valid?, or maybe a separate function?

I have a fairly non-invasive approach for the verification drafted at lgarron@e748508 using separate validation functions, if you'd like to take a look. However, I'm not happy with the fact that it's a fully parallel implementation rather than a DRY one.

[1] https://developers.yubico.com/U2F/App_ID.html
[2] https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html

P-2 Send a valid ServerAuthenticatorAttestationResponse with "tpm" attestation for SHA-1, and check that the server succeeds

TPM with SHA-1.

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

Related to #167

Candidate for a setting in the configuration, then possibly overwritten in each ceremony.

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

https://w3c.github.io/webauthn/#registering-a-new-credential
https://en.wikipedia.org/wiki/Certification_path_validation_algorithm

https://www.w3.org/TR/webauthn/#packed-attestation

I think it might be worth considering in the future making RP name and ID configs that can be set just once during boot. While still supporting the override in the #credential_creation_options method.

Originally posted by @grzuy in #155 (comment)

Since #73 got merged we have not updated valid? method usage in the README for https://github.com/cedarcode/webauthn-ruby#validation-phase nor for https://github.com/cedarcode/webauthn-ruby#validation-phase-1 which show the gem's user that they can optionally pass in a specific rp_id to validate against.

F-2 Send ServerAuthenticatorAttestationResponse with SELF "packed" attestation, that contains full attestation, and check that server returns an error

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

https://www.w3.org/TR/webauthn/#android-safetynet-attestation

We're currently trying to write specs for the callback of the authentication flow and are finding the differences between FakeAuthenticator::Get and FakeAuthenticator::Create a bit difficult to work with. Also, the privateness of the instance variables seems to get in the way as well.

To get some insight, I would suggest attempting to write a test for SessionsController#callback in the webauthn-rails-demo-app.

If you set up the test using attributes from a FakeAuthenticator::Create and then try and test the callback with a separate instance of FakeAuthenticator::Get, they are initialized with a different key and so none of the data signing will be correct.

If following rubygems recommended naming conventions the gem could be named android_safetynet-attestation for a constant called AndroidSafetynet::Attestation.

Unless the constant name is reworked.

Right now in response#credential we're returning the public key in EC point uncompressed format.

We need to change that to become agnostic of the public key type.

Wanted to open up an issue to talk about potentially swapping out the usage of SecureRandom.random_bytes(32) with SecureRandom.hex(32). The challenges would work in the same way but then apps wouldn't have to use this awkward encoding/decoding of the challenge. SecureRandom.hex will be web safe off the bat and provide the same security controls as random_bytes.

I took inspiration from your demo application when integrating this myself, and I noticed that I can add the same key multiple times. Is duplicate key detection not supported yet or did I mess something up in my app? If it's not implemented yet, it would be useful to have.

Right now the default is ES256 and RS256, in that order of preference.

Users may want only a subset of those, or want them in a different order of preference.

[...] In addition, it would be nice if there was a way to "directly" read a response from the client, like the load_from_json method in https://github.com/castle/ruby-u2f , since pretty much every client of the library is going to have to do something similar.

So:

1. Are you willing to stick with a particular encoding suggestion?

2. Would you be willing to add a convenience method for constructing the AuthenticatorResponse classes from JSON?

_Originally posted by @lgarron in #79

I would like to use the credentials across multiple subdomains.

As @bdewater mentioned in #92 it would be nice to know how to use the Webauthn FIDO AppID Extension. I do not fully understand how this works but I also found this AppID example.

In the AuthenticatorResponse the rp_id is compared with the rp_id_hash from the authenticator how does this work if you set a FIDO AppID? Should the authenticator pickup the AppID somehow or is this something that needs to be implemented at the RP or can one do stuff on the client to make this work?

We used bindata gem to parse TPM binary data structure (PR: #162) and turned out to work pretty well.

It would be interesting to see how the same can be done to delegate binary parsing of the AuthenticatorData to the bindata gem, instead of handling that manually in this gem.

We do have test cases testing that the validation "works" but we need more test cases asserting that the attestation statement verification fails if each of the specific requirements are not met individually.

• fido-u2f
• packed / self
• packed / x5c
• android-key
• android-safetynet (moved to #204)

Right now, this library checks that the origin of the client data of an authenticator response (e.g. a user tap for authentication) is identical to original_origin:

https://github.com/cedarcode/webauthn-ruby/blob/master/lib/webauthn/authenticator_response.rb#L63-L65

However, the original origin of the registration actually doesn't matter. What matters is the RP ID of the registration, although this defaults to the domain of the original origin.

Suppose we are either registering or authenticating at a.b.example.com. Then the default RP ID is a.b.example.com, but the operation may also specify an RP ID of b.example.com or example.com (its "registerable domain suffixes").

So the following are the requirements:

• The original registration and the authentication must use the same RP ID.
• The RP ID must be an registerable domain suffix (i.e. ancestor domain that is not a public suffix) of both:
  • the domain used for registration and
  • the domain used for authentication.

If it's still possible at this point in development, I would recommend completely removing the original_origin parameter from AuthenticatorResponse and its subclasses, and just using the rp_id parameter. Unfortunately, I don't have any immediate ideas if you want to maintain backwards compatibility. :-/

This is sort of an epic that would be sort of "Done" once we improve:

• Configuration capabilities
• Credential Creation Options
• Credential Request Options

The documentation on this project includes such examples as:

authenticator_data = "..." # As returned by `navigator.credentials.get`

This doesn't make sense on its own, because WebAuthn mostly uses ArrayBuffers to send/receive data, and those can't be sent over the wire and received in Ruby natively like a string or an array. Different applications handle this differently:

https://github.com/cedarcode/webauthn-rails-demo-app encodes from/to ArrayBuffer by mapping the bytes to 8-bit ASCII:

https://github.com/cedarcode/webauthn-rails-demo-app/blob/3afc964edfd3efeb4ad161d4b08a434e8370fd7a/app/assets/javascripts/application.js#L37-L46

https://github.com/duo-labs/webauthn uses websafe/urlsafe base 64 (and hex):

https://github.com/duo-labs/webauthn/blob/fa6cd954884baf24fc5a51656ce21c1a1ef574bc/static/js/webauthn.js#L227-L231

I think either an ASCII string or regular base 64 would be preferable, assuming the former has no compatibility issues with most JSON transports. In addition, it would be nice if there was a way to "directly" read a response from the client, like the load_from_json method in https://github.com/castle/ruby-u2f , since pretty much every client of the library is going to have to do something similar.

So:

1. Are you willing to stick with a particular encoding suggestion?
2. Would you be willing to add a convenience method for constructing the AuthenticatorResponse classes from JSON?