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 -~----------~----~----~----~------~----~------~--~---
