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.
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. In our case, it only takes 150MB to hold 2 minutes worth of nonce if we are under constant peak load. We don't even need disk for that. Zhihong On Mar 26, 12:36 pm, Brian Eaton <[email protected]> wrote: > Check that the timestamp is recent. Ignore the nonce. > > The nonce checking language in the OAuth spec is fundamentally broken, > it requires infinite server-side storage. > > On Thu, Mar 26, 2009 at 7:29 AM, Zhihong <[email protected]> wrote: > > > Our system is geo-distributed and all our traffic is localized, until > > we started to enforce nonce for OAuth signed messages. > > > To prevent replay of OAuth messages, we have to store timestamp+nonce > > in some kind of replay cache or db for the duration of allowed clock > > skew. We can't find any distributed way to do this. We spent last year > > to make our system distributed and response time is really fast. Now > > the nonce check becomes a bottleneck and all our performance gain is > > lost. So any suggestion would be greatly appreciated. > > > We tried following 2 things, > > > 1. Store replay cache in MySQL locally and replicate all databases. > > Even though this is not 100% replay proof during rep lag, it's > > acceptable considering we shrink replay window to less than 100 ms. > > However, we ran into an issue with MySQL M-M replication . When > > duplicate entries are created in different databases, the replication > > stops. Human intervention is required. > > > 2. Ask consumer to make nonce with a special format. We use a 8-byte > > integer as nonce. First 4 bytes are the IP of SP. When consumer > > resolves the Akamaized hostname of SP, it get a IP of SP host local to > > the consumer host. When we get the nonce, we know where the local > > cache is by checking the IP address. However, our operations are > > against the use of the scheme because we may switch to anycast in the > > future. With anycast, all hosts in different locations share the same > > IP. > > > As you can see, both methods are fundamentally flawed. We are looking > > for a better approach. Thanks! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
