MasterKale / SimpleWebAuthn

WebAuthn, Simplified. A collection of TypeScript-first libraries for simpler WebAuthn integration. Supports modern browsers, Node, Deno, and more.
https://simplewebauthn.dev
MIT License
1.62k stars 137 forks source link

Getting the error "Cannot get schema for 'ECDSASigValue2' target" when calling verifyAuthenticationResponse #485

Closed rpg2014 closed 12 months ago

rpg2014 commented 12 months ago

Describe the issue

Hi, thanks for this library! I'm running into the following error when calling the verifyAuthenticationResponse function in the @simplewebauthn/server package, and was hoping I could get some help debugging. Here is the error and stack trace:

ERROR   Error: Cannot get schema for 'ECDSASigValue2' target
    at AsnSchemaStorage.get (/var/task/index.js:18997:17)
    at AsnParser2.fromASN (/var/task/index.js:19247:50)
    at AsnParser2.parse (/var/task/index.js:19237:26)
    at unwrapEC2Signature (/var/task/index.js:33373:56)
    at Object.verify (/var/task/index.js:33393:32)
    at verifySignature (/var/task/index.js:33212:63)
    at verifyAuthenticationResponse (/var/task/index.js:35174:21)
    at async Object.verifyAuthResponse (/var/task/index.js:35735:28)
    at async VerifyAuthOperation (/var/task/index.js:35784:10)
    at async handle (/var/task/index.js:7366:22)

I'm thinking it's related to the allowed algorithms when generating the registration options, but I haven't been able to resolve it, trying both leaving the supportedAlgorithms field blank and explicitly providing supportedAlgorithmIDs: [-7, -257], when generating the registration options. Do you have any ideas as to what I'm missing here?

Reproduction Steps

I'm able to reproduce it with my local project, I can provide exact steps if needed. Its jsut going through the auth flow.

Expected behavior

I expect the verification to succeed, or at least fail with a different error, (invalid key, verification failed: invalid algorithm or something like that).

Code Samples + WebAuthn Options and Responses

Relevant code snippet:

const verifyInput: VerifyAuthenticationResponseOpts = {
        response: authenticationResponse,
        expectedChallenge: user.currentChallenge,
        expectedOrigin: rpOrigin,
        expectedRPID: rpId,
        authenticator: authenticator as AuthenticatorDevice, // From credential table
      }
      console.log("Verifying object", verifyInput)
      const verification = await verifyAuthenticationResponse(verifyInput);

Below is the JSON object being passed into verifyAuthenticationResponse. I've masked a few of the fields, but let me know if they're needed to debug. I can also provide the options if needed

Verifying object {
  response: {
    id: 'lTsVFz2HyH8dSaMJyQHJNA',
    rawId: 'lTsVFz2HyH8dSaMJyQHJNA',
    response: {
      authenticatorData: 'fVUdNKjnLg7oK56A0wfm18osyPYwxbOOOBFRQu4oFAcdAAAAAA',
      clientDataJSON: 'eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoicjJ3cEI0WnNHVGZHTDlFYkFqUlk3VVR5OW9lOWNhQXJudlFyUTRVU1Z4ayIsIm9yaWdpbiI6IjxtYXNrPiIsImNyb3NzT3JpZ2luIjpmYWxzZX0',
// Signature might be wrong b/c I've masked the origin in the clientDataJSON, but lmk and I can provide the original value
      signature: 'MEUCIQC-qNPV7xLOvLI1d10AtVRi3p9xA7Ilws4PRqJsUL5K9QIgN-KJUkm8Owxap_OqTHKmLndQnkfPmGxW7sXQwOshvoE'
    },
    type: 'public-key',
    clientExtensionResults: {},
    authenticatorAttachment: 'cross-platform'
  },
  expectedChallenge: 'r2wpB4ZsGTfGL9EbAjRY7UTy9oe9caArnvQrQ4USVxk',
  expectedOrigin: '<mask>',
  expectedRPID: '<mask>',
  authenticator: {
    counter: 0,
    credentialPublicKey: Uint8Array(77) [
      165,   1,   2,   3,  38,  32,   1,  33,  88,  32, 127,  38,
        9, 180,  46,  39, 116,  61,  43, 142, 110, 115,  63, 255,
       56, 127, 219, 232,  18,  58, 199, 178, 212, 120,  30, 155,
       92,  37,  30, 114, 128,  31,  34,  88,  32, 111,  34, 241,
       89, 160,  71,  18,  14, 154, 198, 124,  72, 158, 129,  89,
      179,  29,   1,  71,  62,  71, 181,  27,  54,  28,  46, 228,
      204,  71, 108,  86, 186
    ],
    transports: [ 'hybrid', 'internal' ],
    credentialBackedUp: true,
    credentialID: Uint8Array(16) [
      149,  59,  21, 23,  61, 135,
      200, 127,  29, 73, 163,   9,
      201,   1, 201, 52
    ],
    credentialDeviceType: 'multiDevice'
  }
}

Dependencies

$ npm list --depth=0 | grep @simplewebauthn
├── @simplewebauthn/browser@_._._
├── @simplewebauthn/server@_._._
# ...
│ ├── @simplewebauthn/server@8.3.5
│ ├── @simplewebauthn/typescript-types@8.3.4
│ │ ├── @simplewebauthn/browser@8.0.2

Additional context

I've tested explicitly stating the supported algorithms as supportedAlgorithmIDs: [-7, -257],, leaving out [-8], but that leads to the same error.

Let me know if I can provide any additional info to debug this error! Any help you could provide would be awesome, thanks!

rpg2014 commented 12 months ago

Was searching around github a bit more and found this issue: https://github.com/MasterKale/SimpleWebAuthn/issues/61, specifically this comment: https://github.com/MasterKale/SimpleWebAuthn/issues/61#issuecomment-707309815.

I'm using yarn, so adding

"resolutions": {
    "@peculiar/asn1-schema": "2.0.8"
  },

to my package.json (the top level one in a mono-repo), fixed the issue.

I'll leave this issue open for another day or so to increase the visibility, but my issue has been resolved!

Could you look into adding this gotcha to your docs somewhere (maybe a new troubleshooting section on the server page)? I'm sure other people will run into this issue at some point!

MasterKale commented 12 months ago

@rpg2014 Nice find, yarn strikes again 🫠

If you have to specify a resolution in your project, check that the version of asn1-schema is up to date with what's used by @simplewebauthn/server. If you still have to specify 2.0.8 then that sounds like a bug in the @peculiar series of libraries (since those libraries are well past 2.0.8) and I'll look into possibly logging a bug over there.

rpg2014 commented 12 months ago

I've since bumped the version to 2.3.8, the latest, which also works correctly.

Interestingly, removing the "resolutions" doesn't seem to affect it now, it must have fixed the version in the yarn.lock.

Node dependency resolution makes my head hurt, so I'm just going to close this issue, and hope google points people to this fix