Hey Matt, > The oauth_timestamp variable is used so we don't have to keep track of > every nonce every created since the beginning of time. By using the > timestamp we can immediately discard old reply attacks, and with the nonce > we can discard recent replay attacks. If there was no timestamp then nonce > entropy would eventually become an issue, not to mention the speed of > looking up a value in a collection of every nonce ever created.
Not sure if you guys have looked at OpenID implementations, but it deals with the same problem by just discarding all nonces received outside of a certain time frame. There's no need for a timestamp to be sent as doing `(nonce.created_time - now()) > EXPIRATION_WINDOW && nonce.discard()` is pretty straightforward to do on the Service Provider side. I think that's a much better solution as you are then working with relative time to the Service Provider as opposed to absolute time -- which is very likely to be messed up by network lag. And, i just discovered this thread on the OAuth list making *exactly* the same point (but in a much more eloquent way)! http://groups.google.com/group/oauth/browse_thread/thread/a40234e5ae35ad5e/1b76fcd84cf481cb?#1b76fcd84cf481cb > Clock skew > would have to be pretty large for this to be an issue so I'm guessing there > is something else afoot. It seems to be happening with requests with/relating to access tokens and not request tokens... perhaps they take some time to propagate through the cluster? > I see that 4 people have marked issue 281 with a > star and that's what I look for so if you're not one of those that's the > place to register your +1. I starred it already, just wanted to bring it to the attention of more people =) > I'll hopefully work on the OAuth issues today if > Media Temple emails calm down. Thanks again for the great work guys and keep it up! -- love, tav plex:espians/tav | [email protected] | +44 (0) 7809 569 369
