Disallow request in the future.

[fwininger]

Currently we disallow requests on the past to block replay attack, but a request in the future is always valid. It seems to be good to have the same behaviour.

[kjg]

Why would an otherwise valid request in the future be a security risk? A request that is too old might be a reply of an already made request. But if the request is in the future and the signature is valid, what's the concern other than just a longer window in which a reply of a request would still have a valid signature?

[fwininger]

Sorry for the deplay, I was very busy last week.

To prevent replay attack by timestamping, is very important to have a limited windows. Usualy less than 1 second. It's Ok to have +/- 15 minutes, but in our case, if the server is one day late or the client is one day earlier, ApiAuth allows a windows of 1 day for the replay attack.

Some references :

https://en.wikipedia.org/wiki/Replay_attack

Timestamping is another way of preventing a replay attack. Synchronization should be achieved using a secure protocol. For example Bob periodically broadcasts the time on his clock together with a MAC. When Alice wants to send Bob a message, she includes her best estimate of the time on his clock in her message, which is also authenticated. Bob only accepts messages for which the timestamp is within a reasonable tolerance. The advantage of this scheme is that Bob does not need to generate (pseudo-) random numbers, with the trade-off being that replay attacks, if they are performed quickly enough i.e. within that 'reasonable' limit, could succeed.

https://docs.wso2.com/display/IS500/Timestamp+in+WS-Security+to+Mitigate+Replay+Attacks

[kjg]

After some discussion on other issues, I realize that allowing requests in the distant future also allows for a bad actor trying to "guess" the signature for their own crafted request more time to guess it if they set their own request date header super far in the future.

[fwininger]

Thanks :+1: