5 ms·

What is HMAC Authentication why is it useful?

21 points by wolfeidau 14y ago

michaelmior 14y ago
I don't understand why this is a downside "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.
- dzmfh 14y ago
  "snake case your header names (yes this is bad form) before presenting them to your code as the list of header names." 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 https://bugzilla.mozilla.org/show_bug.cgi?id=232030
  - deleted 14y ago
    [deleted]
- Dylan16807 14y ago
  Right, it's not really a disadvantage. But I wouldn't say that it's a requirement, either. A hash where each input character only affects certain output characters is less than ideal, but it's not a critical flaw. You could make one at least as good as md5 if you had the desire to.
  - michaelmior 14y ago
    @Dylan16807 Maybe not a requirement, but this could cause information leakage in some scenarios. I'm also pretty confident I couldn't come up with a hashing scheme as good as MD5. I'll leave that to the crypto pros.
    - Dylan16807 14y ago
      Well it depends on what your criteria are for 'better'. If you have three bcrypts glued together that each get character%3, there are no blatant flaws, it's just going to give you an oversized hash for the security level you get. And each character will affect only one third of the hash.
- wolfeidau 14y ago
  Yes what I should have said was repeatable signatures are hard across large strings. 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.
jemeshsu 14y ago
How does one implement a browser single-app JS client (Backbone, Angular etc) to access server API with HMAC authentication? The secret key will be exposed clearly in the JavaScript client.
- bvdbijl 14y ago
  You give it an API key with limited access
- calpaterson 14y ago
  Unless you can use per-user keys (for example, if you control the server API) you basically can't do it. This is the same problem that DRM faces: you can't give the user the keys to the car and prevent them from driving it.
  - jiggy2011 14y ago
    Wow, that's a great analogy. I will use that next time I have to explain the flaws of client side security to somebody.
antirez 14y ago
Beware of playback attacks, that is, an attacker sniffing the request can reused it as it is even if he does not know the shared secret. 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).
- farhanpatel 14y ago
  would a nonce not work? You could just timestamp your request. And only accept requests in a certain timeframe. http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...
  - antirez 14y ago
    nonce is ok as long as for your application it is ok to expose the client to playback attack only for a limited time. I would go for a pre-request protocol where you perform a request to get a request-seed, and then use it in the next request (and the server will remove it when already used). 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.
    - michaelmior 14y ago
      A nonce when implemented correctly doesn't expose the client to replay attacks at all unless I'm missing something here. When requests come in, store the nonce + timestamp and ensure that requests with the same nonce + timestamp are only ever executed once.
- wolfeidau 14y ago
  I am interested as to how this would be done with a REST API. 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.

21 points by wolfeidau 14y ago

I don't understand why this is a downside "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.

dzmfh 14y ago
"snake case your header names (yes this is bad form) before presenting them to your code as the list of header names." 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 https://bugzilla.mozilla.org/show_bug.cgi?id=232030
- deleted 14y ago
  [deleted]
Dylan16807 14y ago
Right, it's not really a disadvantage. But I wouldn't say that it's a requirement, either. A hash where each input character only affects certain output characters is less than ideal, but it's not a critical flaw. You could make one at least as good as md5 if you had the desire to.
- michaelmior 14y ago
  @Dylan16807 Maybe not a requirement, but this could cause information leakage in some scenarios. I'm also pretty confident I couldn't come up with a hashing scheme as good as MD5. I'll leave that to the crypto pros.
  - Dylan16807 14y ago
    Well it depends on what your criteria are for 'better'. If you have three bcrypts glued together that each get character%3, there are no blatant flaws, it's just going to give you an oversized hash for the security level you get. And each character will affect only one third of the hash.
wolfeidau 14y ago
Yes what I should have said was repeatable signatures are hard across large strings. 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.

jemeshsu 14y ago

How does one implement a browser single-app JS client (Backbone, Angular etc) to access server API with HMAC authentication? The secret key will be exposed clearly in the JavaScript client.

bvdbijl 14y ago
You give it an API key with limited access
calpaterson 14y ago
Unless you can use per-user keys (for example, if you control the server API) you basically can't do it. This is the same problem that DRM faces: you can't give the user the keys to the car and prevent them from driving it.
- jiggy2011 14y ago
  Wow, that's a great analogy. I will use that next time I have to explain the flaws of client side security to somebody.

antirez 14y ago

Beware of playback attacks, that is, an attacker sniffing the request can reused it as it is even if he does not know the shared secret. 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).

farhanpatel 14y ago
would a nonce not work? You could just timestamp your request. And only accept requests in a certain timeframe. http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...
- antirez 14y ago
  nonce is ok as long as for your application it is ok to expose the client to playback attack only for a limited time. I would go for a pre-request protocol where you perform a request to get a request-seed, and then use it in the next request (and the server will remove it when already used). 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.
  - michaelmior 14y ago
    A nonce when implemented correctly doesn't expose the client to replay attacks at all unless I'm missing something here. When requests come in, store the nonce + timestamp and ensure that requests with the same nonce + timestamp are only ever executed once.
wolfeidau 14y ago
I am interested as to how this would be done with a REST API. 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.