3

When registering a new credential as part of WebAuthn, why does the client need to be sent a challenge?

Presumably this is to prevent a replay attack, but wouldn't a replay attack be prevented by TLS already?

johnnyodonnell
  • 153
  • 5

2 Answers2

2

I've asked around a lot about this and haven't been able to find a definitive answer. However, I think the challenge is needed for the following reason:

Replay attacks should mostly be prevented by TLS, but as mentioned here and here it is still possible to execute a replay attack even with TLS by fooling the user or the user's browser to retry a request. Thus, this challenge helps cover a gap in TLS's replay prevention mechanisms.

For example, an attacker could compromise a user's identity in the following scenario if the challenge wasn't required:

  1. A user tries registering a new credential.
  2. That request is held by a man in the middle and a TCP reset is sent to the user's browser.
  3. The user's browser retries the request and successfully registers the new credential.
  4. Within a short period of time, the user decides to deregister their credential.

  5. Again within a short period of time, the man in the middle releases the original request to the server and thus, the credential is re-registered without the user's knowledge.

  6. Sometime later, the man in the middle steals the user's FIDO2 authenticator.

  7. The man in the middle can now pose as the user.

Update

After realizing that a replay attack doesn't have to occur as a result of a compromised node in the network but could also occur as a result of a compromised operating system or compromised browser, I thought of the following example that would be possible without a challenge during registration:

  1. An attacker gains control of a user's browser.
  2. A user registers a new credential and the compromised browser intercepts the PublicKeyCredential before sending it to the server.
  3. The attacker steals the user's FIDO2 authenticator.
  4. The user deregisters their credential.
  5. When the user goes to register a new credential, the compromised browser sends the old PublicKeyCredential instead of a new one.
  6. The attacker can now pose as the user.

A very similar scenario could occur if the user's operating system was compromised and a challenge wasn't used during registration.

Also, these scenarios would only be relevant if a relying party required that registration/authentication be executed with a particular device that the attacker couldn't easily crack.

johnnyodonnell
  • 153
  • 5
0

This aspect comes essentially down to one form of challenge-response authentication.

As you've mentioned it does prevent replay attacks, as the relying party (RP) will (hopefully) choose a challenge based on a random value.

It is also a way of authentication: By signing the unpredictable random value the authenticator proofs in a cryptographically secure way to the relying party (RP) that he is actually in control of the private key belonging to the public key being presented.

Karol Babioch
  • 1,247
  • 8
  • 10
  • This makes sense, but why is this needed for registration? – johnnyodonnell Nov 14 '19 at 23:30
  • Because you want to make sure that the client has control over the private key corresponding to the public key that is being presented to you. Otherwise any client could present any public key. This would lead to broken authentication in the best case ("denial of service") and possibly create vulnerabilities with active man-in-the-middle attacks. – Karol Babioch Nov 14 '19 at 23:41
  • But this challenge isn't signed when it gets returned to the server, so how does it prove that the client has control over the private key? – johnnyodonnell Nov 16 '19 at 02:22
  • Actually, I was wrong. The challenge along with other data is signed and sent to the server as part of registration, and this signature needs to be verified. I guess my question then is: does this actually prevent potential attacks or is it just server-side validation? – johnnyodonnell Nov 16 '19 at 06:05
  • It proves that you have control over the private key. Otherwise you could claim to be the owner of any public key, but the server cannot verify. – Karol Babioch Nov 17 '19 at 08:47
  • Ok, so then it's basically just being used for server-side validation. But then, why is a challenge needed? Couldn't the authenticator just sign the `clientDataJSON` and the server could verify that? – johnnyodonnell Dec 17 '19 at 00:47
  • The challenge is explicitly dedicated to contain random / unpredictable data to prevent replay attacks. – Karol Babioch Dec 17 '19 at 19:19
  • That makes sense, but TLS does this too. So my question is: what does a challenge do that TLS doesn't already do? – johnnyodonnell Dec 18 '19 at 00:31
  • WebAuthn is a (mostly) self-contained protocol, which is secure tries to be secure by itself without relying on the underlying transport protocol. The usage of TLS/HTTPS (http**s** does not gurantee a lot, since there are many potential pitholes misconfiguration, weak cryptography, etc. pp.). Also TLS / HTTPS does not protect the communication between the browser and any potential (hardware) authenticator. – Karol Babioch Dec 19 '19 at 13:33