Challenging times
Never sign a challenge from someone you don’t know
This is the internet advice for the Webauthn/FIDO age.
Within Webauthn, the challenge is a data element that is newly generated by the relying party for each transaction, both create() and get(), with the goal that the value never repeats. And unlike a time-based one-time password (TOTP), the challenge value should not be predictable. This is generally achieved by using a sufficiently random function.
Why challenge?
Webauthn sign on is based on proof of possession of a private key. In order to prove possession, the authenticator creates a digital signature by applying the private key to some data. But not just any data. The authenticator must sign new data that has not been used in a previous transaction. The point is that if you have to sign a new value, you must actually possess the key. You cannot re-use an attestation or assertion signed previously and/or stolen from someone else. (The Webauthn signed data includes the challenge as well as relying party id and authenticator data). The relying party website can then verify that the signed challenge has not been used before and that it matches the challenge that was generated for the corresponding Webauthn request.
But, what a malicious actor could do is act as a man-in-the-middle (MITM), handing a challenge over to the real possessor of the key and trick them into signing it, right?
Well, hopefully that is not so easy in the Webauthn protocol, thanks to another anti-phishing, anti-MITM feature, the origin check. This means that the Webauthn authenticator will reject a request from a website that does not have a secure (HTTPS) web origin (https://www.example.org) that matches a relying party ID (RP ID) mapped to an existing credential on the authenticator. (For create() calls, the secure web origin is used to create the RP ID mapping to the new credential.)
So to recap:
Fraudsters trying to use stolen signed assertions will have a difficult task in that their stolen assertions will be rejected by the relying party website for failing the challenge match
Fraudsters trying to setup phishing sites to relay challenges and signed assertions back and forth between website and victim will have a difficult job as they will fail the Webauthn protocol’s origin check
Where to find the challenge
The challenge can be found within the clientDataJSON ArrayBuffer returned within the response member of the PublicKeyCredential returned from the WebAuthn API create() or get() call.
Takeaway
Let’s make sure your Webauthn implementation isn’t unnecessarily vulnerable in the area of Webauthn challenge / challenges.
If you are a relying party supporting Webauthn sign on, make sure you:
As described in the Webauthn spec, be sure to positively check the value of the challenge returned from every Webauthn create() and get(), in addition to checking the signature.
Don’t just compare the challenge to previously-redeemed challenge values. While this would mitigate replay attacks, a better security approach is to verify positively that the challenge value included and signed in the response is the exact challenge originally generated for that same credential create or get and included in the PublicKeyCredentialCreationOptions / PublicKeyCredentialRequestOptions object initially sent.
The above will require you to store transactional data / state so that matching can be done. This problem is not prescriptively addressed within the Webauthn/FIDO standard, so you will have to determine the approach that works best for you, for example taking into account request context information to ensure the client requesting the challenge is the same as the client redeeming the assertion.
Final note
The above will not protect your implementation if malicious code has been able to switch the challenge you generated for your client for one from a third party, but at least you will be resilient to unnecessary vulnerability to replay and phishing/MITM attacks.