8 ms·
Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?
by apitman 3y ago
Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?
- kortex 3y agoThat interferes with the ability to send multiple requests in-flight at the same time.
- tommiegannert 3y agoThere 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 3y agoDoesn't the server discarding requests with the timestamp beyond a threshold already do windowing but statelessly?
- tommiegannert 3y agoI 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.
- apitman 3y agoGood point. Timestamps probably have a much better set of tradeoffs.
- oefrha 3y agoWhat 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 3y agoI'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 3y agoWell, then you still end up more secure than a regular session token.