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).
I think that actually some kind of get-request-seed request for each request is needed before every call for maximum security. The server will create an entry in the database with an expire set to a given time (for instance 5 minutes, so that flooding the server with get-request-seed will not fill it).
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.
After some consideration I would probably err on the side of caution and either use something like IPSEC AH (Authenticated Header), or build a session key exchange protocol using something akin to it's two phase approach, or even just perform HTTPS based request to exchange session keys.
This session key could then be incorporated into each of the HMAC signatures and would be refreshed on a regular basis similar to how IPSEC does it.
I have used AH in the passed for log data which required the receiver to verify the source for auditing purposes, but this was quite some time ago, these days most systems just either use SSL or IPSEC with ESP.
Reinventing the wheel is probably not the best idea in this case.
Will add a note on this to my blog post for completeness.
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.
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.
Comments
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).
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.
I think that actually some kind of get-request-seed request for each request is needed before every call for maximum security. The server will create an entry in the database with an expire set to a given time (for instance 5 minutes, so that flooding the server with get-request-seed will not fill it).
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.
After some consideration I would probably err on the side of caution and either use something like IPSEC AH (Authenticated Header), or build a session key exchange protocol using something akin to it's two phase approach, or even just perform HTTPS based request to exchange session keys.
This session key could then be incorporated into each of the HMAC signatures and would be refreshed on a regular basis similar to how IPSEC does it.
I have used AH in the passed for log data which required the receiver to verify the source for auditing purposes, but this was quite some time ago, these days most systems just either use SSL or IPSEC with ESP.
Reinventing the wheel is probably not the best idea in this case.
Will add a note on this to my blog post for completeness.
For more information on IPsec see http://en.wikipedia.org/wiki/IPsec
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-with...
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.
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.