CODEWITHSUNDEEP
.netsecurityrest
Brian Mains
Brian Mains

Reputation: 50728

Securing REST Service with HMAC

I've been reading this: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

It's been a really great article. One problem I'm having in my thinking is with this step (in the second half of the article):

4. (OPTIONAL) The only way to protect against “replay attacks” on your API is to include a timestamp of time kind along with the request so the server can decide if this is an “old” request, and deny it. The timestamp must be included into the HMAC generation (effectively stamping a created-on time on the hash) in addition to being checked “within acceptable bounds” on the server.
5. [SERVER] Receive all the data from the client.
6. [SERVER] (see OPTIONAL) Compare the current server’s timestamp to the timestamp the client sent. Make sure the difference between the two timestamps it within an acceptable time limit (5-15mins maybe) to hinder replay attacks.

If a timestamp must be sent, this means it must be in both the hash on the client and the server, so the same exact time must be used. Now, this means that I must send the date as plain text or encrypted, possibly as a header value. Is this correct? Because if it's plain, then couldn't a replay attacker easily modify the date to within an acceptable range (for validation purposes)... So we could encrypt the date, but that would mean both hash and encrypted data is in play, instead of just encrypting all of the data together.

Is my assessment correct, or is there a way to include a date that's secure? Or must it be encrypted in this scenario?

Thanks.

Upvotes: 1

Views: 1096

Answers (1)

mensi
mensi

Reputation: 9826

A HMAC is a message auhentication code. This means if you have some message M you can generate V = HMAC(M, K) with the message and your secret key K. Keep in mind that as long as you keep K secret, noone else will be able to generate the same V except through trying to guess K. This is infeasible if K is big enough.

This also means that everything you include in M cannot be changed without V changing as well, since both M and K are used in the HMAC. So if you include a timestamp, you have to make sure it is included in the HMAC calculation. If an attacker would try to modify the timestamp, the V generated by the HMAC would be different -> you can detect the attempt and discard the request.

A HMAC gives you "Authenticity", meaning you can tell if it came from someone knowing the secret key. Encryption is something different: it gives you "Confidentiality" meaning noone can read the message without knowing the secret key. It is important to keep in mind that encryption does NOT give you authenticity, since an attacker could just change a random bit in the encrypted message. To have both confidentiality and authenticity, you have to use a HMAC as well as encryption.

If you do not need confidentiality, do not encrypt your data, as it would waste CPU cycles and make your system more complicated without gaining anything.

Upvotes: 6

Related Questions