6

I stumbled upon a code where the secret key for HMAC has been hard coded into C# client and server code. I've watched 5 videos about HMAC and many articles and none of them doesn't specify how the secret key for HMAC should be exchanged or stored.

Can anybody elaborate on that subject? Because if the secret key is transmitted through the web this compromises whole algorithm. Is there any point to use HMAC if you already use the HTTPS at the same time?

Improve this question
3
  • 2
    The same as how the encryption key is exchanged, I presume. A common solution is to generate double the bytes you need for encryption and exchange those, then the receiver splits it in half and uses one for encryption and the other for HMAC.
    – Awn
    Commented Dec 29, 2016 at 12:19
  • 2
    @Eclipse About which enryption key do you write? Public key for https? If yes, then still public key is well, public and does not compromise RSA algorithm, but sending secret key for HMAC gives the man in the middle all the information he needs to calculate HMAC for message changed by him. So how the shared secret which is this secret key kept secure?
    – Yoda
    Commented Dec 29, 2016 at 13:39
  • Use NaCl instead of worrying about this. I guarantee whatever solution you come up with won't be as good as NaCl. That's not an insult, simply an outcome of high probability.
    – Awn
    Commented Dec 31, 2016 at 15:59

1 Answer 1

Reset to default
2

HMAC provides message integrity and authentication. If you receive a message with a correct HMAC on it, you know that:

  • the message is intact;
  • the sender has the key.

Since the sender has the key, you know the message originates from somebody you gave the key to. If you distribute the key only to known users, you can be sure that the message originated from a known user.

Sometimes the key is used by the same system and no key exchange is necessary. For example, a password reset functionality on a web site may create a HMAC and send that by email. If you click the link in the email, the same site verifies the HMAC. Since the HMAC is created and verified by the same software, not verification is necessary.

In other applications, for example in OpenID, each client has its secret shared with the server. When adding a client to OpenID you also need to specify the key for the HMAC operation. This configuring step is done once.

In your example with the C# client and server, the key is hardcoded. The server can then verify that the request really originates from the client. However, it would be pretty easy to extract the key from the client and forge a request.

A key exchange method for HMAC does not really make sense. It may be usable in another cryptographic mechanism, but normally HMAC keys are fairly static.

Finally you ask how this works in conjuction with HTTPS. HTTPS provides server authentication. You could use client certificates to achieve client authentication, but this is not enabled by default. With HTTPS, messages can't be modified in transit. So the only thing that the HMAC solution could add is client authentication.

Improve this answer
2
  • Referring to the last paragraph. If the applications I work with already use HTTPS the HMAC doesn't add any value? Reffering to the 4th paragraph: " This configuring step is done once." how is done securely? Would it be clever to store Secret Key for every user in the database on the server side? But how to store it on client's side in XML in clear text?
    – Yoda
    Commented Jan 2, 2017 at 8:29
  • Or if I use HTTPS and send hashed password inside HMAC I can authenticate the message and that's why I need HMAC? Session cookie is not enough?
    – Yoda
    Commented Jan 2, 2017 at 8:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .