Matt, your solution sounds similar. There are two differences, I think. The first difference is when the callback is sent. Either way works, but there's slightly less state to maintain if it's sent along during the redirect vs. the request token request. Is the server-to-server communication channel necessary if the Consumer -> SP redirect is signed? I don't think it is...
The other difference is that it seems you're not issuing a callback token for the manual case, where there's no callback URL. I think you need a callback token either way. There's still a timing attack for the manual case because the attacker could sit on the callback page for the consumer and repeatedly submit the request token key, possibly beating the victim there after the token has been authorized. The solution is to have the user enter two numbers in the manual case. The request token key, and the callback nonce (which could be a short PIN, as Eran suggested). Mike On Thu, Apr 23, 2009 at 11:27 AM, Jim Patterson <[email protected]> wrote: > For consumers that don't support callbacks you can have the user type in > the token manually. > > Here is how we (Yammer) have changed our protocol to close this security > hole and still allow our API clients to function until a new OAuth spec is > completed. You can see a diagram of the new authorization flow at the bottom > of the page. > > http://www.yammer.com/api_oauth_security_addendum.html > > On Apr 23, 2009, at 11:15 AM, Ryan Kennedy wrote: > > A lot of these solutions require something to be passed back by the > provider in the callback, however callbacks aren't required in OAuth because > they don't work for non-browser devices. How are you going to pass something > back to the application when there's no mechanism to do so? > > Ryan Kennedy > > ------------------------------ > *From:* Matt Sanford <[email protected]> > *To:* [email protected] > *Sent:* Thursday, April 23, 2009 10:31:23 AM > *Subject:* [oauth] Re: OAuth Security Advisory > > Hi Mike, > I have a proof of concept I think might be similar to this. It works > like so: > > 1. When the consumer gets the request_token the provide the callback URL. > » Note this is server-to-server communication, unavailable to the user. > > 2. The user is redirected to the service provider to authorize the > application. > > 3. Once authorized the user is redirected the the callback URL with an > additional callback_token parameter. > > 4. When requesting the access_token the consumer provides the > callback_token. > » If the request_token has a callback but the access_token request does > not have the callback_token access is denied and the request token is > invalidated. > » If the request_token had no callback but the access_token request > does access is denied and the request token is invalidated. > » If the callback_token does not match the one on record access is denied > and the request token is invalidated. > > By sending the callback in the server-to-server communication it is not > available to the user/attacker. This is also a signed request so > man-in-the-middle changes to the oauth_callback will be caught by the > signature. The final step of checking the callback_token prevents other > man-in-the-middle style attacks after the user has been returned to the > consumer app. Does this sound like what you're suggesting? > > Thanks; > – Matt Sanford / @mzsanford > Twitter API Developer > > > > On Apr 23, 2009, at 10:16 AM, Mike Malone wrote: > > How bout this... > > Instead of the provider signing the callback URL, the consumer signs the > redirect to the SP using its consumer and request tokens. This will prevent > an attacker from changing the callback URL, but still allow the consumer to > specify any redirect URL it wants (provided the SP accepts any callback > URL). > > This reduces the threat to what Eran called a "timing attack" in his blog > post. There's still a possibility that the attacker could beat the victim > back to the callback after the request token is authorized. To mitigate > this, the provider could generate a callback nonce that must be provided > during the request/access token exchange. This nonce would be appended as a > querystring param to the callback URL. > > I think these two changes eliminate the threat with the smallest change to > the spec, and without requiring either side to maintain a lot of extra state > across steps. The SP needs to maintain the callback nonce, but it can be > stored and expired with the request token. > > The drawback is that the manual auth process would require the user to > enter two numbers at the consumer after authorizing a token: the request > token key and the callback nonce. > > Mike > > On Thu, Apr 23, 2009 at 9:25 AM, Shan <[email protected]> wrote: > >> >> I have a simple idea to propose not as a solution, but hopefully to >> give someone an idea toward a true solution: >> >> What if the callback URL is signed on the provider's end using the >> consumer's secret key? The drawback is it puts the burden on the >> consumer to close the security hole by checking the signature, and as >> such the provider has no way of knowing if an application is secure or >> not. >> >> Shan >> >> > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
