No, the spec is broken. Here's the entire nonce and timestamp section: ------------------------- Unless otherwise specified by the Service Provider, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests.
The Consumer SHALL then generate a Nonce value that is unique for all requests with that timestamp. A nonce is a random string, uniquely generated for each request. The nonce allows the Service Provider to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel (such as HTTP). ------------------------- and then in the verifying requests section: ------------------------- When verifying a Consumer signature, the Service Provider SHOULD check the request nonce to ensure it has not been used in a previous Consumer request. -------------------------- There are several points that make it impossible to implement the spec as written and expect it to scale well: 1) monotonically increasing timestamps: imagine a consumer that sends two requests one second apart, with timestamps t and t+1. There is *no guarantee* that they arrive at the service provider in the same order. So service providers can't implement the time stamp check recommended. 2) synchronized consumer clocks: imagine two different computers using the same consumer key: they must synchronize *every single request they make* to make sure they don't violate the monotonically increasing time stamp rule. So consumers can't implement the time stamp check either. 3) service provider expected to synchronize with consumer clock: the spec doesn't give the service provider permission to verify that the time stamp is current. Instead the service provider is told to verify that time stamp/nonce pairs are unique. Imagine a consumer that sends a request with timestamp T and nonce N. Imagine a MITM captures that request. The service provider must remember T and N *forever* in order to prevent the MITM from replaying the request. So there are some MUSTs and SHOULDs in there that really can't be implemented. Instead people do what you've done, and check that the time stamp is within a reasonable window. Cheers, Brian On Thu, Mar 26, 2009 at 7:00 PM, Zhihong <[email protected]> wrote: > > The spec must have been changed. This sentence sounds correct to me, > > The Consumer SHALL then generate a Nonce value that is unique for > all requests with that timestamp. > > Thanks! > > Zhihong > On Mar 26, 5:48 pm, Brian Eaton <[email protected]> wrote: >> On Thu, Mar 26, 2009 at 2:22 PM, Zhihong <[email protected]> wrote: >> > We can't afford to ignore nonce. Timestamp can't prevent replay. We >> > allow clock skew up to 1 min so there is a 2-min window, in which the >> > message can be replayed. This is a risk we don't want to take. >> >> OK, this is challenging then. I think you've got two choices: >> - look into alternatives to nonce to mitigate the risk of replay >> (https and idempotent requests come to mind.) >> - look at alternate replication schemes. The choice of synchronous vs >> asynchronous nonce replication is the big one, I suspect. >> >> The body signing spec I've been working on >> (http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/4/spec....) >> might help you get to idempotent requests. >> >> You could also look at implementing the timestamp_refused error in the >> problem reporting extension. That would let you cut your time window >> from two minutes to something shorter. Clients would need to >> automatically adjust to the time stamp on your server. >> >> > I don't know why you think storage is infinite. It's very limited >> > because nonce has limited size and life, and servers have limited >> > bandwidth. >> >> That's the right way to do it, but it's not actually what the spec >> says to do. Check out this >> thread:http://markmail.org/message/apniux5s3iio7fln. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
