madwizard-org / webauthn-server Goto Github PK

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

Would it be possible to change the setter functions in the RegistrationOptions to return self instead of void? This would make it possible to be able to chain those and write something like this:

$opts = RegistrationOptions::createForUser($userIdentity)
            ->setExcludeExistingCredentials(true);
            ->setTimeout(20);
            ->setResidentKey(ResidentKeyRequirement::REQUIRED);
            ->setUserVerification(\MadWizard\WebAuthn\Dom\UserVerificationRequirement::REQUIRED);

instead of this

$opts = RegistrationOptions::createForUser($userIdentity);
$opts->setExcludeExistingCredentials(true);
$opts->setTimeout(20);
$opts->setResidentKey(ResidentKeyRequirement::REQUIRED);
$opts->setUserVerification(\MadWizard\WebAuthn\Dom\UserVerificationRequirement::REQUIRED);

kinda like the ServerBuilder works, this could be done without breaking existing code i think

See w3c/webauthn#1275

Hi, I have been having a look at your project and it looks great.

I have also been trying to code the server side of webauthn and bumped into a problem with point '7.2. Verifying an authentication assertion' ( https://www.w3.org/TR/webauthn/#verifying-assertion ), and I think you might want to know about it.

Verification step 16 says: "Using the credential public key looked up in step 3, verify that sig is a valid signature over the binary concatenation of aData and hash." Doing just that I always got a signature that did not match with 'sig'. I spent a lot of hours checking my code without finding anything wrong. I inspected several source codes, including yours, and I found out that this repository, https://github.com/fido-alliance/webauthn-demo, did the verification differently. I tried it and it worked.
The correct concatenation that produces a valid signature is:
rpIdHash + flags (1 byte) + signature counter (4 bytes) + clientDataHash

I hope it helps. I suppose the W3C specification will be updated. By the way, I am using a 'FIDO2 Security Key' by Yubico.

Regards.

Level 2 of the spec changes the type of some fields from strict (exhaustive) enumerations to more flexible DOM strings. Make sure the library does not strictly validate these fields if not necessary.

The x and y coordinates of the public key should be on the elliptic curve to prevent certain attacks.

Hi there,
I am curious if you have a planning for releasing the first stable version.
Maybe you need some help?

When parsing the unique field from pubArea during an attestation verification, unique is a TPM2B_PUBLIC_KEY_RSA only if the TPMI_ALG_PUBLIC is TPM_ALG_RSA. If TPMI_ALG_PUBLIC is TPM_ALG_ECC, unique is a TPMS_ECC_POINT. See TPM Rev 2.0 part 2, structures, section 12.2.3.2.

Relevant code is at:

Use LoggerAwareInterface to add logging to services.

See w3c/webauthn#1453. The format is not standardized yet.
This post contains useful links.

https://bugs.chromium.org/p/chromium/issues/detail?id=847878
Chrome violates the spec here. Wait for fix in Chrome or add check for emtpy ArrayBuffer userHandle and treat as null.

Currently there is no test data for ECC TPM statements so this is not implemented yet.