Two different defences
Timestamps and nonces solve related problems and behave differently when you replay a request.
A timestamp bounds how long a captured request stays valid. The server compares the value against its own clock and accepts a request only inside a window. The window is usually short, which is why a capture can work in the morning and fail after lunch with no other change.
A nonce makes a request single-use. The server remembers values it has seen and refuses a repeat. A nonce does not expire in the same way a timestamp does. It becomes invalid the moment it is used.
Telling them apart
The two produce different failure patterns, and the pattern tells you which one you are dealing with.
- Send the identical request twice within a second. If the first passes and the second fails, uniqueness is enforced.
- Wait past the suspected window and send again. If it now fails where it previously passed, freshness is enforced.
- Change only the timestamp and resend. If the response changes at all, the timestamp is signed or directly validated.
- Change only the nonce and resend. If the response changes, the nonce is part of the signed material.
Clock problems that look like tampering
Some failures come from the client clock rather than the protocol. A device with a wrong timezone or a drifting clock can produce timestamps outside the accepted window while the code is correct.
- Wall clock differences between the device and the server.
- Time zones applied twice, so the value is offset by hours rather than seconds.
- Monotonic timers used where the server expects wall time, or the reverse.
- Milliseconds where the server expects seconds, which produces a timestamp far outside any window.
Unit errors are common and cheap to rule out. Check the magnitude of the number before you assume a cryptographic problem.
Reproducing freshness correctly
You cannot replay your way past a freshness check. You have to generate the value at send time, which means two things need to be true.
- You know exactly which fields the timestamp covers. Changing any covered field requires a new timestamp and a new signature.
- Your client's clock is correct, or you can read the server's notion of time from an earlier response and use it.
For nonces, the requirement is different. You need to generate values in the same shape the server expects, and you need to know whether the server tracks them per session, per device or globally. Getting that wrong produces intermittent failures rather than consistent ones.
Where this sits in the wider job
Freshness handling is one part of reproducing a signed request. The rest is the key material, the exact signed string, the header set and the session flow around the call. Solving only the timestamp produces a request that is valid for a few minutes and fails in production.
Related work
Reviewed 28 September 2026 · SReverse research desk