Also, using sha1_hex(secret+...) and calling it HMAC is a slippery slope (see http://netifera.com/research/flickr_api_signature_forgery.pd...). Although it's seemingly not exploitable due to the structure of the data, look into using a proper HMAC (RFC 2104) to prevent length-extension attacks.
Whoah. That is a good catch. I admit, I skimmed this, saw "hmac_for", thought "I'm not a Perl programmer", and assumed it was HMAC.
Guys, fix this ASAP. SHA1(secret || data) (secret-prefix MAC) is totally insecure. (In practice, every valid forgery to this MAC is going to look like x-y-z-useragent-GIBBERISH-evil-content, but you don't want to be relying on that for your security).
Thank you! This will be closed up by end of this week. As I wrote in the article and in the presentation, one of main points of open sourcing it is to have people smarter than myself look at the crypto and protocols to find any issues like this. It should be fairly easy to close up.
Guys, fix this ASAP. SHA1(secret || data) (secret-prefix MAC) is totally insecure. (In practice, every valid forgery to this MAC is going to look like x-y-z-useragent-GIBBERISH-evil-content, but you don't want to be relying on that for your security).
Embarrassing (for me).