3
$\begingroup$

Would a challenge response HMAC authentication be secure?

i.e.

  1. Client sends id
  2. Server sends a challenge(32byte value)
  3. Client calculates hmac_sha256 of the challenge value with its key and sends the reply
  4. Server verifies the reply
$\endgroup$
3
$\begingroup$

That's as secure as a symmetric challenge-response authentication can be. Some remarks:

  • In an authentication protocol, the only assurance is that the authenticated party participated in the protocol. It could well be that there's a man-in-the-middle.
  • Step 1 (sending client ID) can be coalesced into 3 if all clients have to authenticate that way regardless of ID.
  • At step 2, the server's challenge should be unique and unpredictable. Making that reliable is less easy than it seems.
  • At step 4, the server must be able to get or regenerate the client's key, from a database of random keys, or a master key and a key derivation function.

The big problems are

  • Said database or master key could leak for the server, and poof goes all security. One good mitigation is to use a security token (HSM, Smart Card..) in the server, programmed so that it can only check the response to challenges.
  • The ultimate solution from the standpoint of avoiding server leaks is when there is noting secret in there. Challenge/response replacing HMAC with a signature allows just that.
  • Authentication is one thing, securing what follows next is better. That's why we have authentication-and-key-agreement protocols. Good ones resist man-in-the-middle.
  • The client's key (symmetric or asymmetric) can be compromised on the client side. A password (and proper password-based key derivation) to encipher the key-at-rest in the client might help, but is less convenient than directly using the password as an authentication mean. That's why we have SRP and ISO/IEC 11770-4.
$\endgroup$
  • $\begingroup$ Awesome thanks. Regarding step 2, would a cryptographically random base64 string be secure enough? Also forgot to mention that this whole thing is happening on top of HTTPS(websockets). $\endgroup$ – ErlangWannabe Oct 1 '17 at 17:10
  • $\begingroup$ @ErlangWannabe: yes, a "cryptographically random base64 string" will do; if it is 32-character (resp 44), it is practically as good as if it had 192 (resp.256) bits of entropy, that's fine for all purposes. Getting that on a properly running device is easy, the hard part is detecting failure (perhaps adversarially induced) leading to non-cryptographically random challenge (e.g. repeating), while not stopping operation per bad luck. "On top of HTTPS" is vague; if the server is authenticated (by way of a server certificate) and a ciphersuite immune to MitM is running, that does help. $\endgroup$ – fgrieu Oct 1 '17 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.