To mitigate the playback attack it is possible to use a challenge-request protocol where the server sends to the client a large random number that the client needs to add to the HMAC input (and that invalidates after receiving the request so that no further requests can be made using the same random number).
Would it be required that a client perform a pre call for each request, or for a window of requests possibly.
I have seen this sort of thing in SOAP aka WS-Security with their SecureToken.
I mite try put something together an example and see how it works out.
Thanks for the comment.
When the request "seed" is used, it gets removed from the list of active seeds, so it can not be used again.
There is still a man in the middle attack:
1) The attacker intercepts our request, send it to the server, and reply to the real client with an error code. 2) This will force the real client to send the request again, this time the attacker will not interfere with the request.
The result is that the request was performed two times instead of one.
http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...
Another thing that makes sense is to use a nonce plus adding the IP address in the string to sign, with server side verification that the IP matches. So at least the playback attack needs to be performed in near time with the same IP as the originating client, that is considerably harder for the attacker to do.
"Cryptography is hard, a single character difference will result in a completely different value."
HMAC is designed to guarantee the integrity of the message. If a single character difference didn't result in a completely different value, the whole method would be completely flawed.
From RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", §4.2, "Message Headers": Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
"Use content MD5 at both ends of the conversation." Yeah.. no: https://bugzilla.mozilla.org/show_bug.cgi?id=232030
Having just worked on this with a few people implementing independent implementations everyone got at least one character wrong, and therefore a complete missmatch of signature.
For those involved this was pretty frustrating.
