A Serious Security Issue in Challenge-Response

2026-05-28T00:47:56+08:00

A challenge-response approach works by sending a random string ('nonce') to the person whose identity is to be verified, and asking them to sign that string using their private key. However, this poses a very serious security issue.

For example, Alice wants to verify Bob. However, Mallory comes between them. Then the following happens:

1. Alice sends the challenge to 'Bob', who is impersonated by Mallory.
2. Mallory impersonates Alice to forward that challenge to Bob and request a response.
3. Bob sends the response back, and then Mallory forwards the response.

In this scenario, Mallory has successfully impersonated Bob to Alice, and can now carry out MITM attacks.

The solution is to avoid using merely a random string as the challenge. A good challenge should contain at least the following:

1. the identification information about the verifier's and the verifiee's trust anchor (for example, an OpenPGP fingerprint);
2. the identification information about the channel (for example, the location when verifying face-to-face, the JID along with the OMEMO fingerprints when verifying on XMPP, the Matrix ID of both parties and the room when verifying on Matrix);
3. a timestamp;
4. the nonce, which is the random string.

In other words, the challenge should bind the verifier's and the verifiee's identities, the authenticated channel or session context, a timestamp for freshness, and a nonce. The verifier must compare the signed identity claims with the authenticated transport metadata.

In that case, Mallory will need to alter the channel context to deceive Bob (otherwise Bob will immediately identify the problematic challenge and refuse to respond), which will render the response invalid for Alice to verify because the challenge has been altered.

For even stronger security, verify each other mutually.