chkaufmann 17 Posted November 10, 2022 Hi, for my REST Api I create a key with timestamp in the client application. On the server I check if the key is valid and if it's not expired. The problem here seems to be, that some client computers, who send valid requests, don't have the clock correctly set and I have differences of several minutes in the timestamps. Should I allow a bigger differences for expiration times? Right now I test with 30 seconds. Or is there another trick to solve this problem? Regards Christian Share this post Link to post
Fr0sT.Brutal 900 Posted November 10, 2022 (edited) If you absolutely trust your clients, you can send them server's timestamps to use. But I'd advice to store such info in the server itself. Edited November 10, 2022 by Fr0sT.Brutal Share this post Link to post
chkaufmann 17 Posted November 11, 2022 19 hours ago, Fr0sT.Brutal said: If you absolutely trust your clients, you can send them server's timestamps to use. But I'd advice to store such info in the server itself. I was thinking of something like that. Get the server timestamp and then keep the difference in the application. But why could it be dangerous to send the server timestamp in an API Request? Christian 1 Share this post Link to post
Fr0sT.Brutal 900 Posted November 11, 2022 (edited) 5 hours ago, chkaufmann said: Get the server timestamp and then keep the difference in the application. What's the need in storing differences? Just add asking the server for correct timestamp before generating new key. Moreover, why you need timestamp at all? If you try to unload server from storing and housekeeping current keys and leave it fully to clients, this seems not a good idea (probably OK for 80s when communication was open and built on trust). 5 hours ago, chkaufmann said: But why could it be dangerous to send the server timestamp in an API Request? Not the timestamp itself. Malicious client could try to generate a bad key if the server internally extracts some data from it. F.ex., if it contains expiration period, a client could try to set it to 1000 years. Or to 30.02.<current year>. Edited November 11, 2022 by Fr0sT.Brutal Share this post Link to post