OAuth timestamp sensitivity
dound
Registered Users Posts: 72 Big grins
Lower bound: It looks like timestamps more than 300 seconds before the current time.
Upper bound: However, there doesn't seem to be any upper bound on how far after the current time they can be (it didn't seem to mind even if I set the timestamp a billion seconds [~30 years] in the future). Is this the intended behavior? It seems like there might need to be a cap on how far in the future something is too, otherwise you'll end up having to save all these way off in the future timestamp/nonce combinations for 30 years to prevent reply attacks.
Anyway, I'll of course just use the current timestamp since there's no chance it will sit around for 5 minutes before I manage to send it off to SmugMug.
Vulnerable to replay? Also, I noticed that I can resend a given timestamp/nonce and the SmugMug API happily re-executes it. It doesn't seem like the API is checking for reused timestamp+nonce combinations. Are you seeing this too?
Upper bound: However, there doesn't seem to be any upper bound on how far after the current time they can be (it didn't seem to mind even if I set the timestamp a billion seconds [~30 years] in the future). Is this the intended behavior? It seems like there might need to be a cap on how far in the future something is too, otherwise you'll end up having to save all these way off in the future timestamp/nonce combinations for 30 years to prevent reply attacks.
Anyway, I'll of course just use the current timestamp since there's no chance it will sit around for 5 minutes before I manage to send it off to SmugMug.
Vulnerable to replay? Also, I noticed that I can resend a given timestamp/nonce and the SmugMug API happily re-executes it. It doesn't seem like the API is checking for reused timestamp+nonce combinations. Are you seeing this too?
0
Comments
Cheers,
David
SmugMug API Developer
My Photos
SmugMug API Developer
My Photos