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