Josh, current we don't sign the authorization URL so an attacker can do what ever they want. Once we start signing the callbacks, this won't be possible.
On Sat, Apr 25, 2009 at 7:05 PM, Josh Fraser <joshf...@gmail.com> wrote: > > How would attackers be able to inject a callback w/o having access to > the consumer secret? > > > On Apr 25, 3:46 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > > Zack, very good points. We have been probably over thinking this a bit > and > > have gotten off topic. > > > > Our focus should be: > > > > + Secure the callback in the authorization URL from tampering > > + Make sure the user that authorized the request token is the same user > that > > requested it > > > > The first issue can be solved by signing the callback URL if it is > included > > in the authorization URL. Since devices / apps wont' use a callback, the > > consumer > > should set a flag during provider registration saying it will not use > > callbacks. This will prevent attackers from injecting a callback. > > This still allows for clean authorization URLs that are easy to type > > manually. > > > > We can solve the second issue by requiring a "confirmation token" be > > included with the callback. > > If there is no callback, the user must manually enter is confirmation > back > > into the consumer. > > The token should be type able, but long enough to make brute attacks > > unlikely. > > > > These changes are easy to implement and don't really affect the current > > oauth flow. > > > > On Sat, Apr 25, 2009 at 4:31 PM, Zachary Voase < > disturb...@googlemail.com>wrote: > > > > > > > > > I completely agree. The whole point of this thread (I thought) was to > > > develop a solution to a very specific security hole; this has already > > > been done with three things: once-only exchanging, signed/pre- > > > specified callbacks, and the concept of a callback nonce (a.k.a. > > > authorization token, and a host of other names) (have a look at a > > > previous post by Mike Malone for the details). These things require > > > absolutely *no* change in user experience, they keep all of the burden > > > of verification/authentication on the service provider (where it > > > should be), and they need only minimal changes to the specification. > > > We can't trust consumers to verify things, because that means the > > > service provider is trusting a third-party with the security of its > > > users' data. > > > > > I suppose what I'm saying is that if you think you've got a totally > > > better authorization protocol/strategy worked out, great, but let's > > > try and keep the focus on patching this security hole rather than > > > completely rewriting the spec. > > > > > You might also be interested in reading the OAuth design goals for an > > > explanation of why things are the way they are: > > >http://oauth.net/about/design-goals > > > > > Regards, > > > Zack > > > > > On Apr 25, 10:56 pm, "J. Adam Moore" <jadammo...@gmail.com> wrote: > > > > Yeah, I have that at my bank and it sucks all kinds of hell. Thank > god > > > > I can just Google my mother's maiden name to reset my password when > > > > that fails. If a system is designed to work only by relying upon > > > > people to not be stupid it will fail. You can't outwit a fool; only > > > > fools try. I really need to finish my post on this. It has pictures > > > > and everything. Should clear up some confusion people might have. > > > > > > I am not saying that your method is forever flawed, but why change > > > > OAuth when it works just fine? Remember, the problem we are facing is > > > > still theoretical and the solution I proposed doesn't break anyones > > > > current or past work or understanding. > > > > > > On Apr 25, 1:33 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > > > > > > > The only place that a phishing attack would occur in the signed > > > > > authorization proposal is the authorization URL. > > > > > An attacker could lure an user to click on a link that directs the > user > > > to a > > > > > clone of the provider and steal the users credentials > > > > > when logging in. The best way to prevent this is users being > careful to > > > > > check the address bar and making sure the site they are at > > > > > is indeed the provider's site. Another layer that can help prevent > this > > > is > > > > > by using images that are displayed on the provider's site during > login. > > > Some > > > > > banks use this during login. You first give your username and hit > > > enter. > > > > > Next the bank shows an image you set when you signed up. You > verifty > > > this is > > > > > the right image and provide your password. > > > > > This isn't really something oauth should mandate. It is up to the > > > provider > > > > > to add this layer of security on their own. > > > > > > > On Sat, Apr 25, 2009 at 3:24 PM, Brian Eaton <bea...@google.com> > > > wrote: > > > > > > > > On Sat, Apr 25, 2009 at 1:11 PM, J. Adam Moore < > jadammo...@gmail.com > > > > > > > > wrote: > > > > > > > The problem itself is REALLY > > > > > > > specific: Phishing. Like fish in a barrel phishing. The > solution is > > > to > > > > > > > take away their bullets, and is not to try and harden the > barrels > > > or > > > > > > > educate the fish to dodge bullets. > > > > > > > > The problem is very similar to phishing, in that it requires some > > > > > > element of social engineering to exploit. However, the current > > > > > > protocol allows a phishing attack where everything the user sees > is > > > > > > completely in context and true. The session fixation > vulnerability > > > > > > allows perfect phishing. > > > > > > > > I just reread the protocol you proposed above, and I'm pretty > sure it > > > > > > doesn't actually fix the session fixation attack. You need some > kind > > > > > > of a callback token passed through the user's browser back to the > > > > > > consumer. (If you were including that, sorry, I missed it.) > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
