[apitman]

Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?

[oefrha]

What clock attack? You validate the timestamp on the server and reject if the timestamp is too far off. The same request being repeatable within say 30s isn’t a problem in 99% of cases.

[apitman]

I'm referring to threat models where the attacker might be able to manipulate time on the server, either directly or through NTP servers, etc. Personally it's not something I would worry about but I've heard it discussed and was wondering how big a concern it is.

[oefrha]

Well, then you still end up more secure than a regular session token.

[kortex]

That interferes with the ability to send multiple requests in-flight at the same time.

[apitman]

Good point. Timestamps probably have a much better set of tradeoffs.

[tommiegannert]

There could be a window: the last N sequence numbers are kept in a set, where N is higher than the number of concurrent requests.

[willvarfar]

Doesn't the server discarding requests with the timestamp beyond a threshold already do windowing but statelessly?

[tommiegannert]

I responded to this:

>> Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?

> That interferes with the ability to send multiple requests in-flight at the same time.

I.e. it was assumed there was a sequence number, and I refuted that it disallows concurrent requests.

In general, I agree a signed timestamp is fine.