On Wed, Mar 24, 2010 at 9:46 PM, Luke Shepard <lshep...@facebook.com> wrote: > This is probably a stupid question, but why do we need accurate timestamps? > Why is it not sufficient to use a monotonically increasing call_id to > prevent replay attacks? (this is how the Facebook sig algorithm works)
Monotonically increasing counters don't scale well in distributed systems. It is rapidly changing state that needs to be synchronously replicated across lots of clients and servers. (Wow, I hadn't realized that FB requires call_id to monotonically increase. I may have to eat my words about this not scaling well. =) Bearer tokens eliminate the need for timestamps - authorization servers and protected resources need roughly synchronized clocks, but clients don't need to worry about it. Challenge-response protocols eliminate the need for timestamps, but add an extra round trip. The OAuth 1.0 extension to report server-side time basically makes the protocol fall back on challenge-response. Folks who really can't live with bearer tokens should probably use this approach. Cheers, Brian > On Mar 24, 2010, at 9:28 PM, Raffi Krikorian wrote: > > but timestamps are still necessary in the signature method? > > On Wed, Mar 24, 2010 at 7:31 PM, Allen Tom <a...@yahoo-inc.com> wrote: >> >> In our experience at Yahoo, we’ve found that many clients don’t have the >> right time. You’d think that NTP would have solved this by now, but it >> hasn’t for a surprising number of clients. >> >> Are timestamps really necessary in Oauth 2.0? In OAuth 1.0a, timestamps >> are included in the signature to protect against replay attacks. This is not >> really necessary in Oauth 2.0 since signatures are optional when SSL is >> used. >> >> Allen >> >> >> On 3/24/10 6:26 PM, "Paul Lindner" <lind...@inuus.com> wrote: >> >> Right now if a client with an inaccurate clock makes an OAuth call they >> are rejected. OAuth Problem Reporting >> <http://oauth.pbworks.com/ProblemReporting> includes a mechanism to send >> the server's concept of 'now' to the client: >> >> The parameter named oauth_acceptable_timestamps consists of two numbers in >> decimal notation, separated by '-' (hyphen). It's the range of timestamps >> acceptable to the sender. That is, it means the sender will currently accept >> an oauth_timestamp that's not less than the first number and not greater >> than the second number. >> >> >> With that data a client can maintain a time skew value to translate >> localized time to the server's (reliable) time. >> >> We've found that this problem is more widespread than I would have >> imagined. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Raffi Krikorian > Twitter Platform Team > http://twitter.com/raffi > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
