Protect server time information from manipulation about hawk HOT 5 CLOSED

Indeed.

Another approach would be to not send the time info from the server in the challenge, but only send an offset / staleness period in the case when the server decides that it's not fresh enough. Saves bits, reduces use of crypto, limits the exposure to only the failure case.

from hawk.

The goal is to put all the burden of time sync on the client and not involve the server other than giving a point of reference. See http://www.links.org/?p=1297 (which was posted while I was talking to Ben...)

from hawk.

Yes, absolutely. I was just wondering if it was necessary to put this info in the initial challenge; protecting it is likely to be difficult/expensive, I suspect.

from hawk.

The question is if this is going to save another round trip, it might be worth it. If Hawk is ever used in a discovery scenario, the client will need it.

Going to try: the server sends the client a MAC together with its time value. The client returns the time value, the MAC, whenever it relies on that time value as an offset. The server checks the mac to make sure its really a time value that it issued.

from hawk.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

from hawk.