[oauth] Re: why not have server generate nonce values
I get what you mean now but following issues will make this scheme very hard to implement, 1. Where does first nonce come from when consumer gets request token? All OAuth message needs to be signed with nonce. 2. How do you track next nonce when you have multiple sessions going on at the same time. Remember HTTP is stateless. You must use some other parameters to track the session. 3. How do you keep client/server in sync? For example, server forgets about next nonce when it restarts. Some sync process is needed to recover from this. 4. Consumer would be limited to serialize all its requests. Currently, a consumer can send multiple requests to get protected resources upon receiving access token. With this scheme, it's not possible anymore. You can get away with most of the issues by asking for a nonce every time but that adds a round-trip for each request. Zhihong On Mar 26, 11:44 am, joshthecoder wrote: > I don't think an extra round trip would be needed to get the nonce > from the server. > > Get request token --> Service provider > Consumer <-- Request token along with next nonce in the header > Get access token --> Service provider > Consumer <-- Access token along with next nonce > > Get protected resource --> Service provider > Consumer <-- Protected resource with next nonce in header > > So each time we send a request to the service provider we get in > return the next nonce value in the response header. > There is no extra trips to the server since we just carry the next > nonce on the response packet. > > On Mar 26, 9:34 am, Zhihong wrote: > > > Don't you need another trip to get the server generated nonce? So a > > round-trip is saved by using client generated nonce. > > > I just posted help in another thread > > >http://groups.google.com/group/oauth/browse_thread/thread/ff93d23e073... > > > Our problem would be solved if the nonce is generated by server but I > > don't think this justifies an extra round-trip. > > > Zhihong > > > On Mar 25, 5:23 pm, joshthecoder wrote: > > > > I've been reading up on the oauth specs and when came to the section > > > about nonce and timestamps I wondered "why not have the server send > > > the nonce?". > > > > Benefits of this: > > > + Server only needs to track the last nonce it sent to validate the > > > next request > > > + Don't need to store every nonce ever used > > > > When the server responds back from the previous request it can include > > > the next nonce value in the header. > > > So when we construct our next signature we have our next nonce. > > > Attackers still can't construct a valid signature even if they see the > > > next nonce. > > > > So why have the client generate the nonce on the fly? I'm no security > > > professional, so I might be overlooking a flaw with the above method. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
This is not an OAuth issue by how it is implemented. There is nothing to prevent servers from not requiring registration. It is part of the discovery spec. EHL > -Original Message- > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > Of Martin Atkins > Sent: Thursday, March 26, 2009 4:38 PM > To: oauth@googlegroups.com > Subject: [oauth] Re: Security through obscurity? > > > Eran Hammer-Lahav wrote: > > Comparison with OpenID at this stage is not that relevant because > while > > OAuth protects real data and resources, OpenID at most reveal some > silly > > information about you (SREG). So it is ok to let the use decide how > they > > share some minimal set of data about them, read only, and without > > updates. Not so much when you can access their electronic wallet... > > > > As a user I cannot grant access to my data to applications I trust if > the application vendor has not made a business deal with the company > that's hosting my data. > > I can't host my own data because OAuth is set up in such a way to > require every combination of (consumer, provider) to be pre-registered > out of band, and no application vendor is going to have pre-registered > with my one-off, self-hosted data service. > > So I'm stuck. I can't force the application vendor to agree to the > service provider's terms, and I can't provide my own service. What am I > supposed to do? > > The "electronic wallet" example is a distraction because OAuth as > deployed today is used for much less critical things like updating my > location in FireEagle, or retrieving the data from my address book on > GMail. > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Replay Prevention/Geo-distribution
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 wrote: > On Thu, Mar 26, 2009 at 2:22 PM, Zhihong 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
Eran Hammer-Lahav wrote: > Comparison with OpenID at this stage is not that relevant because while > OAuth protects real data and resources, OpenID at most reveal some silly > information about you (SREG). So it is ok to let the use decide how they > share some minimal set of data about them, read only, and without > updates. Not so much when you can access their electronic wallet... > As a user I cannot grant access to my data to applications I trust if the application vendor has not made a business deal with the company that's hosting my data. I can't host my own data because OAuth is set up in such a way to require every combination of (consumer, provider) to be pre-registered out of band, and no application vendor is going to have pre-registered with my one-off, self-hosted data service. So I'm stuck. I can't force the application vendor to agree to the service provider's terms, and I can't provide my own service. What am I supposed to do? The "electronic wallet" example is a distraction because OAuth as deployed today is used for much less critical things like updating my location in FireEagle, or retrieving the data from my address book on GMail. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Replay Prevention/Geo-distribution
On Thu, Mar 26, 2009 at 2:22 PM, Zhihong 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.html) 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Replay Prevention/Geo-distribution
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 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 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
Comparison with OpenID at this stage is not that relevant because while OAuth protects real data and resources, OpenID at most reveal some silly information about you (SREG). So it is ok to let the use decide how they share some minimal set of data about them, read only, and without updates. Not so much when you can access their electronic wallet... EHL On 3/26/09 1:58 PM, "Martin Atkins" wrote: Eran Hammer-Lahav wrote: > You are looking at it wrong. > > (insert IANAL disclaimer here) > > Yahoo! Issues client credentials to a specific, authenticated user. That > user has accepted our legal terms which include not sharing those > credentials with anyone else. If you break this agreement (which is a > legally binding contract), and someone abuses Yahoo! Or a Yahoo! User > using those credentials, you are liable and if Yahoo! Gets sued, you are > likely to get involved in this... > > So while the legal agreement cannot stop you, it takes care of the risks > Yahoo! Cares about which is liability and a way to protect our users > within the framework the law allows. > If the Yahoo! developer agreement prohibits sharing the consumer credentials then I have no problem with that, since Yahoo! is effectively saying that desktop apps are not allowed, which is fine. All I'm arguing is that if you're going to allow desktop apps (in other words, if you're going to allow app developers to share their consumer credentials with third parties) then you might as well not require consumer credentials at all, since at that point they are providing no value. There is also the issue that requiring application pre-registration prevents OpenID-style ad-hoc service discovery, which is actually what I care more about. The OpenID model is to trust the user to make the call about whether they trust the consumer, but I'll concede that some people consider this model to be flawed because the user is somehow unfit to make this decision. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
Eran Hammer-Lahav wrote: > You are looking at it wrong. > > (insert IANAL disclaimer here) > > Yahoo! Issues client credentials to a specific, authenticated user. That > user has accepted our legal terms which include not sharing those > credentials with anyone else. If you break this agreement (which is a > legally binding contract), and someone abuses Yahoo! Or a Yahoo! User > using those credentials, you are liable and if Yahoo! Gets sued, you are > likely to get involved in this... > > So while the legal agreement cannot stop you, it takes care of the risks > Yahoo! Cares about which is liability and a way to protect our users > within the framework the law allows. > If the Yahoo! developer agreement prohibits sharing the consumer credentials then I have no problem with that, since Yahoo! is effectively saying that desktop apps are not allowed, which is fine. All I'm arguing is that if you're going to allow desktop apps (in other words, if you're going to allow app developers to share their consumer credentials with third parties) then you might as well not require consumer credentials at all, since at that point they are providing no value. There is also the issue that requiring application pre-registration prevents OpenID-style ad-hoc service discovery, which is actually what I care more about. The OpenID model is to trust the user to make the call about whether they trust the consumer, but I'll concede that some people consider this model to be flawed because the user is somehow unfit to make this decision. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
You are looking at it wrong. (insert IANAL disclaimer here) Yahoo! Issues client credentials to a specific, authenticated user. That user has accepted our legal terms which include not sharing those credentials with anyone else. If you break this agreement (which is a legally binding contract), and someone abuses Yahoo! Or a Yahoo! User using those credentials, you are liable and if Yahoo! Gets sued, you are likely to get involved in this... So while the legal agreement cannot stop you, it takes care of the risks Yahoo! Cares about which is liability and a way to protect our users within the framework the law allows. EHL On 3/26/09 12:15 PM, "Martin Atkins" wrote: Allen Tom wrote: > Martin Atkins wrote: >> Indeed, but if for example I take the oauth consumer key and secret out >> of the Movable Type FireEagle plugin and use it in my service then I can >> use FireEagle without agreeing to the legal terms > > Sure, but the developer that was issued the CK had agreed to the terms, > and is legally bound to them. For instance, the developer might have > agreed to not be abusive, or to not use the CK for commercial purposes. > So if I use MT's key to be abusive, would Yahoo! shut off every MT instance that's using FireEagle and/or sue Six Apart? (Assuming, for the sake of this argument, that I'm not a Six Apart employee.) As long as it's possible to make requests without agreeing to the terms -- which is quite obviously is -- the terms are worthless. I'm not arguing that consumer credentials should be removed entirely -- they do clearly have value in situations where they can be kept secret -- but they ought to be used only in situations where a special level of access is granted, and the business agreement in that case should include a requirement that the credentials be kept secret. Ultimately it's up to the user to make the final decision about whether to trust the calling application; it's not like allowing unregistered apps would create a security free-for-all. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
Allen Tom wrote: > Martin Atkins wrote: >> Indeed, but if for example I take the oauth consumer key and secret out >> of the Movable Type FireEagle plugin and use it in my service then I can >> use FireEagle without agreeing to the legal terms > > Sure, but the developer that was issued the CK had agreed to the terms, > and is legally bound to them. For instance, the developer might have > agreed to not be abusive, or to not use the CK for commercial purposes. > So if I use MT's key to be abusive, would Yahoo! shut off every MT instance that's using FireEagle and/or sue Six Apart? (Assuming, for the sake of this argument, that I'm not a Six Apart employee.) As long as it's possible to make requests without agreeing to the terms -- which is quite obviously is -- the terms are worthless. I'm not arguing that consumer credentials should be removed entirely -- they do clearly have value in situations where they can be kept secret -- but they ought to be used only in situations where a special level of access is granted, and the business agreement in that case should include a requirement that the credentials be kept secret. Ultimately it's up to the user to make the final decision about whether to trust the calling application; it's not like allowing unregistered apps would create a security free-for-all. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
Martin Atkins wrote: > Indeed, but if for example I take the oauth consumer key and secret out > of the Movable Type FireEagle plugin and use it in my service then I can > use FireEagle without agreeing to the legal terms Sure, but the developer that was issued the CK had agreed to the terms, and is legally bound to them. For instance, the developer might have agreed to not be abusive, or to not use the CK for commercial purposes. Allen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Is 4-legged OAuth possible?
Mike Malone wrote: > You can kind of delegate individual requests with OAuth, depending on > what the use case is, by generating a signed URI and handing it off to a > fourth party to use. > > In the TweetDeck/TwitPic case, TweetDeck could generate a signed URI for > POSTing the desired tweet, then pass the URI off to TwitPic to actually > make the request. > > Note that this only works if the fourth party doesn't need to modify the > request parameters. However, they _can_ modify the request body as long > as the content-type isn't application/x-www-form-urlencoded (and the > provider hasn't implemented the draft spec for OAuth request body signing). > This workaround of not using application/x-www-form-urlencoded points to what we really need for this solution to work: We need the ability for an app to generate a signature that allows another party to "fill in the blanks" while restricting what the other party is allowed to specify. I'm not sure exactly how this manifests on the wire, but at a high level that would facilitate use-cases such as Amazon S3's browser upload API, where the app gives the browser access to upload a file but the exact content of the payload is determined after the signature is generated. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
Eran Hammer-Lahav wrote: > That's simply not true. When you manually register an application you agree > to legal terms with how you may or may not use the user's data you are > accessing and other legal requirements. Without this agreement, users could > sue the service provider for bad acts by the application. > Indeed, but if for example I take the oauth consumer key and secret out of the Movable Type FireEagle plugin and use it in my service then I can use FireEagle without agreeing to the legal terms. You can find these here: http://code.sixapart.com/trac/mtplugins/browser/trunk/FireEagle/plugins/FireEagle/fireeagle.pl This means that in practice anyone can actually use FireEagle without agreeing to its terms by using those credentials, and therefore the consumer key and secret are providing no legal value whatsoever. It would seem to me to be far more effective to just assume that the client cannot be trusted at all and behave accordingly. Mozilla doesn't need to make a legal agreement with Google in order for Firefox to be able to load GMail. It's a complete fantasy that non-browser apps are somehow any more verifiable than browsers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Is 4-legged OAuth possible?
You can kind of delegate individual requests with OAuth, depending on what the use case is, by generating a signed URI and handing it off to a fourth party to use. In the TweetDeck/TwitPic case, TweetDeck could generate a signed URI for POSTing the desired tweet, then pass the URI off to TwitPic to actually make the request. Note that this only works if the fourth party doesn't need to modify the request parameters. However, they _can_ modify the request body as long as the content-type isn't application/x-www-form-urlencoded (and the provider hasn't implemented the draft spec for OAuth request body signing). Mike On Thu, Mar 26, 2009 at 5:37 AM, Ben Laurie wrote: > > On Wed, Mar 25, 2009 at 4:13 PM, Ivan Kirigin > wrote: > > > > Hi, > > > > I recently integrated Twitter's OAuth into my site, http://tipjoy.com > > > > It's a great user experience and a lot like Facebook Connect. > > > > But I ran into a problem when developing our API for Twitter > > applications to use Tipjoy for payments. OAuth tokens aren't > > transferable like a username & password. For example, a Twitter user > > on TweetDeck can input a username & password, which lets TweetDeck > > post a picture to TwitPic. If TweetDeck were granted OAuth access to > > the user's Twitter account, TwitPic couldn't verify the access tokens > > easily, and couldn't communicate to Twitter with them. > > > > How can we power this 4-legged OAuth? Twitter could act as an > > intermediary, to tell TwitPic that the request from TweetDeck is > > authorized. > > Aha. This is delegation, something I wanted to put into OAuth first > time round but, well, there was resistance :-) > > I believe the IETF are also interested in delegation. > > > > > I'm told Facebook is coming up with a solution for Facebook Connect. > > As the environment for social apps becomes more connected, this > > communication between 3rd parties about users on the OAuth provider > > become more important. > > > > What do you all think? > > > > Thanks, > > Ivan > > http://tipjoy.com > > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Replay Prevention/Geo-distribution
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 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: why not have server generate nonce values
Have a look at how the HTTP Digest uses server generated nonce values, I think what happens is that in the same HTTP connection you have two requests, the nonce is returned in the first which you then use in the second. Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: why not have server generate nonce values
I don't think an extra round trip would be needed to get the nonce from the server. Get request token --> Service provider Consumer <-- Request token along with next nonce in the header Get access token --> Service provider Consumer <-- Access token along with next nonce Get protected resource --> Service provider Consumer <-- Protected resource with next nonce in header So each time we send a request to the service provider we get in return the next nonce value in the response header. There is no extra trips to the server since we just carry the next nonce on the response packet. On Mar 26, 9:34 am, Zhihong wrote: > Don't you need another trip to get the server generated nonce? So a > round-trip is saved by using client generated nonce. > > I just posted help in another thread > > http://groups.google.com/group/oauth/browse_thread/thread/ff93d23e073... > > Our problem would be solved if the nonce is generated by server but I > don't think this justifies an extra round-trip. > > Zhihong > > On Mar 25, 5:23 pm, joshthecoder wrote: > > > I've been reading up on the oauth specs and when came to the section > > about nonce and timestamps I wondered "why not have the server send > > the nonce?". > > > Benefits of this: > > + Server only needs to track the last nonce it sent to validate the > > next request > > + Don't need to store every nonce ever used > > > When the server responds back from the previous request it can include > > the next nonce value in the header. > > So when we construct our next signature we have our next nonce. > > Attackers still can't construct a valid signature even if they see the > > next nonce. > > > So why have the client generate the nonce on the fly? I'm no security > > professional, so I might be overlooking a flaw with the above method. > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: why not have server generate nonce values
Don't you need another trip to get the server generated nonce? So a round-trip is saved by using client generated nonce. I just posted help in another thread http://groups.google.com/group/oauth/browse_thread/thread/ff93d23e0734a7d8?hl=en Our problem would be solved if the nonce is generated by server but I don't think this justifies an extra round-trip. Zhihong On Mar 25, 5:23 pm, joshthecoder wrote: > I've been reading up on the oauth specs and when came to the section > about nonce and timestamps I wondered "why not have the server send > the nonce?". > > Benefits of this: > + Server only needs to track the last nonce it sent to validate the > next request > + Don't need to store every nonce ever used > > When the server responds back from the previous request it can include > the next nonce value in the header. > So when we construct our next signature we have our next nonce. > Attackers still can't construct a valid signature even if they see the > next nonce. > > So why have the client generate the nonce on the fly? I'm no security > professional, so I might be overlooking a flaw with the above method. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Replay Prevention/Geo-distribution
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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Is 4-legged OAuth possible?
On Wed, Mar 25, 2009 at 4:13 PM, Ivan Kirigin wrote: > > Hi, > > I recently integrated Twitter's OAuth into my site, http://tipjoy.com > > It's a great user experience and a lot like Facebook Connect. > > But I ran into a problem when developing our API for Twitter > applications to use Tipjoy for payments. OAuth tokens aren't > transferable like a username & password. For example, a Twitter user > on TweetDeck can input a username & password, which lets TweetDeck > post a picture to TwitPic. If TweetDeck were granted OAuth access to > the user's Twitter account, TwitPic couldn't verify the access tokens > easily, and couldn't communicate to Twitter with them. > > How can we power this 4-legged OAuth? Twitter could act as an > intermediary, to tell TwitPic that the request from TweetDeck is > authorized. Aha. This is delegation, something I wanted to put into OAuth first time round but, well, there was resistance :-) I believe the IETF are also interested in delegation. > > I'm told Facebook is coming up with a solution for Facebook Connect. > As the environment for social apps becomes more connected, this > communication between 3rd parties about users on the OAuth provider > become more important. > > What do you all think? > > Thanks, > Ivan > http://tipjoy.com > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
