How does challenge-response authentication with symmetric crypto (HMAC) work, and what advantage does it have over sending the password?
Both sides share a secret key sk. Server sends a random challenge; Alice replies with HMAC(sk, challenge). The secret never leaves Alice's machine.
Setup: Alice and Bob both have a shared secret key sk (out-of-band exchange, or derived from a password).
Login:
- Alice → Bob:
"I'm Alice". - Bob → Alice: random
challenge(a nonce). - Alice → Bob:
HMAC(sk, challenge). - Bob: computes
HMAC(sk, challenge)himself, compares. OK / NOK.
Why this is better than password-over-TLS:
- The secret never crosses the network — no eavesdropper can steal it, even over plain HTTP.
- No replay — each login uses a fresh challenge, so a captured response can't be re-sent.
- The server doesn't see Alice's secret in plaintext form (it sees the HMAC, but verifying it requires also having
sk).
Downsides:
- Both sides must store the secret. If the server is breached, every shared key leaks (worse than salted password hashes).
- Requires a real client (browser JS, mobile app) — not usable on a generic login form.
This is the core pattern behind WPA2 EAP-PSK, Kerberos pre-auth, and many API HMAC schemes.
Tip: HMAC, not raw hash. HMAC(key, msg) is specifically designed to be safely keyed — naive hash(key ‖ msg) constructions are vulnerable to length-extension attacks (the historic mistake behind early Flickr API signing).