Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's say I have a web "widget" that a customer could include on their website. They would include the widget by adding an iframe that points to a URL on my site. I want to ensure that my widget can only be used by paying customers so I was thinking of using an HMAC (HMAC-SHA256 specifically) to verify the customer like so:

  • The URL would contain a customer ID (randomly generated 6 character hexadecimal number), a timestamp (the current time in seconds since UNIX Epoch), and the HMAC "signature". Since the widget is displayed in an iframe, all of these parameters would be sent clear-text (as a GET request).
  • The "signature" would be computed based on the URL (since there are multiple widgets), the customer ID, and the timestamp, with a (randomly generated) secret key that would be given to the customer.
  • On the server, the timestamp is checked to ensure that it falls within a specific window (15 minutes, for example) to prevent replays, and then the signature is checked by recomputing the HMAC and comparing.

I patterned my design off Amazon's web services, but Amazon's scheme requires that some of this data is passed via HTTP headers which would be encrypted over SSL. I don't have that luxury, since everything needs to be passed via GET parameters.

Does this sound reasonably secure? A coworker mentioned that it may not be very secure because all of the inputs to the HMAC algorithm are available in clear-text. An attacker would still need to figure out the way in which the URL, customer ID, and timestamp are combined to create an input to the HMAC algorithm, but, if they did, then they'd have both the input and output. My coworker worried that this information could be used to obtain the secret key via brute force or rainbow tables. Everything I've found via searching seems to indicate that our sun would explode before brute force would finish, and rainbow tables don't work on HMAC's, but the wide world of cryptography is very foreign to me. Plus, most of the answers I've found are 2+ years old and much can change... maybe some new vulnerability was found in the last 2 years or something...

So, is this reasonably secure? And, if not, what can I do to improve security?

share|improve this question
HTTPS encrypts the GET request as well, not just the headers. – Dennis Dec 27 '13 at 18:57
Oh ya, that's right... for some reason I was thinking only the headers and body get encrypted. My bad. – hailtiki Dec 29 '13 at 4:06
up vote 0 down vote accepted

Yes, this sounds secure to me. HMAC, like any secure MAC algorithm, is designed to be existentially unforgeable under chosen-plaintext attacks: that is to say, even if the attacker was allowed to request from you the MACs for any set of messages they wanted, they would not be able to compute a valid MAC for any message they didn't request it for.

(Of course, this is only guaranteed to hold if the hash algorithm used to instantiate HMAC meets the security assumptions set out in the HMAC security proof. In practice, though, secure cryptographic hash algorithms like the SHA-2 family are believed to meet these assumptions — and, in any case, HMAC is a very robust construction and seems to be very tolerant of even rather poor hashes like MD5.)

Of course, I'm assuming that all clients will be getting their own HMAC keys, so that you can revoke keys if they're compromised or simply if the client stops subscribing to your service.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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