title: API authentication using timestamp : What to do when the client's time setting is changed?
body: <p>I am implementing an REST API authentication system.</p>
  
  <p>I am basically using the method explained in this site:</p>
  
  <p><a href="http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/" rel="noreferrer">http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/</a></p>
  
  <p>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...</p>
  
  <p>I won't bother explaining the details. The important part is that <strong>I am using a timestamp</strong> in order to prevent "replay attacks".</p>
  
  <p>Quoting from the site, it explains:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>The problem I am facing now is that <strong>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</strong>.</p>
  
  <p>Is there no way around this? Do I have to give up on using the timestamp?</p>
  
  <p>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.</p>
  
  <p><strong>Note:</strong> 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.</p>