API authentication using timestamp : What to do when the client's time setting is changed?

Question

I am implementing an REST API authentication system.

I am basically using the method explained in this site:

http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

Basically it uses the request body to create a hash, sends it to the server along with the actual request, the server recreates and compares it, and what not...

I won't bother explaining the details. The important part is that I am using a timestamp in order to prevent "replay attacks".

Quoting from the site, it explains:

Compare the current server’s timestamp to the timestamp the client sent. Make sure the difference between the two timestamps it within an acceptable time limit (5-15mins maybe) to hinder replay attacks.

The problem I am facing now is that if the client's clock setting is modified, it may cause unexpected API authentication failures, since the timestamp varies between the client and the server.

Is there no way around this? Do I have to give up on using the timestamp?

I would highly appreciate it if anyone can help me out with a solution for this timestamp problem, or with any other way which I can prevent replay attacks.

Note: I am aware that issuing a nonce to the client is an excellent way to prevent "replay attacks", but I want to make that my last resort, since the implementation cost of creating a nonce-issuing-API and the backend to manage the nonce is too large.

Answer 1

When comparing the server's time stamp with the client sent timestamp, it does not have to be THE client timestamp, but the previuously timestamp sent by the server to the client. You can never rely on client's own timestamp as it could be anything or it could be in the other side of the world.

When the client connects to the server the first time, the server can reply a timestamp from itself and stored on the client, the next time the client must send the last timestamp received.

Answer 2

I think you want your timestamp to be UTC time as the updated article indicates.