Tell the user to type a pin or something like that. EHL
On 4/23/09 11:15 AM, "Ryan Kennedy" <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
