I'm exploring using HMAC style secret-key authentication with timestamp expiry, but am struggling to get my head around how you validate the timestamp portion.

On the client side you would do:

my_hmac = hmac(my_secret, my_values)

Where you would have a timestamp field in my_values.

On the server (where you also know my_secret) you would attempt to rebuild the HMACd string with the request parameters:

my_hmac_to_compare = hmac(my_secret, my_values_from_http_request)

Is it simply a case of embedding the timestamp as a parameter so it's hashed in to the HMAC string and then ensuring the timestamp is within N minutes of when we process the request?

I have odd visions of having to iterate over 5 minutes worth of timestamps, rebuilding the HMAC string on the server attempting to find the needle-in-the-haystack that will generate the correct HMAC string.

Bonus question: Is there a consensus on how you would initially transfer the secret key to a client from a server? It obviously becomes "dirty" after it goes over the wire, but in a user facing application you can't have someone pasting in an extensive secret key, especially if it's a mobile client.

  • 1
    Just add the timestamp in clear to the token. Something like timestamp || HMAC(key, timestamp) – CodesInChaos Nov 27 '13 at 16:30
  • 1
    For the larger problem: Why not simply throw SSL at the problem? – CodesInChaos Nov 27 '13 at 16:31
  • Have you solved this problem? – WKPlus Apr 12 '17 at 3:44

Your Answer

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

Browse other questions tagged or ask your own question.