fido-tools / fido2-library Goto Github PK

when i try to install it with
npm i --save fido2-library

I get this error

npm ERR! code EINTEGRITY
npm ERR! sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA== integrity checksum failed when using sha512: wanted sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA== but got sha512-VLRAcYdF+nZcgiDBM8AjKRkDyQIe5sNMySr4YaxR210yxsjvqGyOAbM5GW0ZzqOPIRhqQOuAYWxrtFoifphIng==. (93368 bytes)

Ubuntu 20.04.2
node 14.17.0
npm 6.14.13

Hello

In W3C Recommendation Section 5.8.1, TokenBindingStatus should be "present" or "supported".
So, there seems to be a mistake in this library's validator.js L.280.

Hi,

I'm getting following error while installing fido2-library

` tarball data for fido2-library@https://registry.npmjs.org/fido2-library/-/fido2-library-2.6.0.tgz (sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA==) seems to be corrupted. Trying again.

tarball data for fido2-library@https://registry.npmjs.org/fido2-library/-/fido2-library-2.6.0.tgz (sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA==) seems to be corrupted. Trying again.

EINTEGRITY
sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA== integrity checksum failed when using sha512: wanted sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA== but got sha512-VLRAcYdF+nZcgiDBM8AjKRkDyQIe5sNMySr4YaxR210yxsjvqGyOAbM5GW0ZzqOPIRhqQOuAYWxrtFoifphIng==. (93368 bytes)`

Greetings, fire here!

@JamesCullum recently invited @fire-bot to this repository. Before fire is enabled, @JamesCullum needs to complete a few steps:

Complete fire setup now

Only @JamesCullum will be able to enable fire using the above link. If someone added fire by mistake, feel free to remove @fire-bot from your repo's collaborators.

Hello @JamesCullum,

as specified by WebAuthn specification the options for assertion generation (PublicKeyCredentialRequestOptions) also include allowCredentials field to filter what credentials could be used during login process. However I see that the library does not include this option. I'am working on adding this. When I'll finish, I'll send a pull request to you. Let me know if this is ok for you.

Thank you,

Enrico.

Hi @JamesCullum seems that there's an issue in npm with latest release (v2.6.0)

root@scw-221e2d:~/dev# npm i [email protected]
npm ERR! code EINTEGRITY
npm ERR! sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA== integrity checksum failed when using sha512: wanted sha512-rMySX7kJkQaFPNQxkwUEN3RdGFiUqRw8WIZPgggdyRdL1IH7mKjWgOcZwGWoUQBUAKgE6YYbEETGE0N1S7I6VA== but got sha512-VLRAcYdF+nZcgiDBM8AjKRkDyQIe5sNMySr4YaxR210yxsjvqGyOAbM5GW0ZzqOPIRhqQOuAYWxrtFoifphIng==. (93368 bytes)

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2021-06-11T16_08_04_700Z-debug.log

The issue seemed to happen on different environments, also got a fresh copy of package and compared sha512 manually and it was returning VLRAcYdF+nZcgiDBM8AjKRkDyQIe5sNMySr4YaxR210yxsjvqGyOAbM5GW0ZzqOPIRhqQOuAYWxrtFoifphIng== (hex: 54b440718745fa765c8220c133c023291903c9021ee6c34cc92af861ac51db5d32c6c8efa86c8e01b339196d19cea38f21186a40eb80616c6bb45a227e98489e).
Could you please investigate it further?

jwk-to-pem v2.0.0 makes use of a vulerable version of elliptic, which could allow an attacker to determine a user's private key (advisory). jwk-to-pem hasn't yet been patched, but wanted to put this on your radar for when it is.

Relevant PR:
Brightspace/node-jwk-to-pem#84

Hi @JamesCullum could you do the same here? This feature seems really helpful for verification on subdomains and makes the lib more compatible with libs in other languages like ruby

Currently Safari supports webauthn, but the counter is always set to zero.

The signature counter is not implemented and therefore it is always zero. Secure Enclave is used to prevent the credential private key from leaking instead of a software safeguard.

(Source: https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/)

I would propose that the prevCounter verification step is skipped in validation if the prevCounter expectation and the counter value submitted in the client authData is both 0. This in line with Ackermann Yuriy's recommendation

If counter in DB is 0, and response counter is 0, then authr does not support counter, and this step should be skipped

https://herrjemand.medium.com/verifying-fido2-responses-4691288c8770

Current behavior is that WebAuthn fails on WebKit browser due to rollback error.

EDIT: Created a PR #8