Using HMAC to secure a "widget"

Question

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?

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. — bmatcuk, Dec 29 '13 at 04:06

score 0 · Accepted Answer · answered Dec 27 '13 at 18:37

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.

Using HMAC to secure a "widget"

1 Answers1