Home/ Questions/Q 8684767
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T22:23:23+00:00

The 1st case would require to generate for each communication a HMAC identifying the

  • 0

The 1st case would require to generate for each communication a HMAC identifying the request, so the server can re-generate it to make sure the client is authorized (because the HMAC is encryped with a private key that is only known by the server and the client), while the 2nd one only requires the service to issue the certificate (or token) once, and keep it live for some minutes -ex. 15 minutes-. Of course to prevent MITM or Replay attacks it must be sent only over SSL, with all the conseguences (more bandwitdh and more CPU requirements).

Personally I find the 1st to be not only simpler but also stronger, because each request has its own unique data, while the 2nd relies on the SSL certificate integrity (I’m not saying that’s easy to crack a signed SSL certificate, but if someone would break it all the traffic would be sniffed for all communications).

So I find them to have the following pro/cons:

  • HMAC pros: unique token for each request, can be really secure against MITM and Replay attacks -by using unique data to compose the signature and a timestamp-, easy to implement
  • HMAC cons: requires the server to work for each single request to re-generate the token
  • Token pro: one token for multiple requests, useful on services that require multiple client actions
  • Token cons: requires SSL for all communications.

I think I’d need to set up some tests to get a final answer, but I’d love to hear if someone has already some knowledge or some tought based on old experiences.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    HMACs and PKIs are designed to solve very different problems.

    If you are trying to protect the message from being modified in transit, then HMAC is designed to solve that problem, and will serve you well.

    If you are trying to prevent the message from being read in transit, than your only option is a PKI (such as SSL). A PKI provides a strictly stronger guarantee than an HMAC though — after all, if one can’t read the message, it is awfully difficult to make meaningful modifications to that message 🙂

    If you transmit the secret used by a HMAC over a PKI, note that it is impossible for the HMAC to be more secure than the PKI system. After all, if you break the PKI then you can just read the HMAC secret.

    Most all of the bandwidth overheads of SSL are going to be in the handshaking process; if you’re going to be sending anything over SSL there’s little reason to not send the rest of your communications over SSL.

    • 0