I completely agree that having a single point of authentication is ideal. However, security and usability have always been an inharmonious pair. When a new pattern offers a significant security improvement in exchange for an marginal usability sacrifice, we adopt it. The danger of the redirection pattern is that it asks for a usability sacrifice in exchange for an imaginary security improvement. The only security value is that users MAY, over time, grow skeptical of entering their credentials in third party apps. This can be easily mitigated by more sophisticated phishing sites. The bottom line is, we gain so little from redirection that isn't worth the usability penalty no matter how unpalatable it is to enter your creds in a third party app. I also argue that redirection also trains users to trust being redirected to a site that can easily mask its URL with a few characters of JavaScript. In my opinion, this is a much less acceptable habit. The best solution I have seen was offered here: http://blog.atebits.com/2009/02/fixing-oauth/ . Principally, this article argues that we should convince OS and browser manufactures to create platform level authentication gateways. This way, your consumer code triggers a platform based dialog that sends your credentials to the provider. Though it is an up hill battle to disseminate a new standard, I think this is a win-win. Thanks for responding and I hope we can keep this debate alive.
On Sep 29, 9:54 am, Breno <breno.demedei...@gmail.com> wrote: > There are several issues with this argument. > > It assumes that the provider authenticates the user via password. One of > the reasons while this is so prevalent today is because of lack of viable > delegation mechanisms such as Oauth. > > It is a bad idea to enter your password everywhere even on trusted sites. > Sites that host applications in multiple domains often implement single > sign-in systems both for usability and security reasons, namely to control > which code paths handle credentials > > The user may not be prompted for the password at the provider if she has > authenticated recently, or the password may be saved for the provider and > easily available. > > The user may have extensions to Antivirus software that manages passwords > and warns against password reuse. > > On Sep 29, 2009 8:22 AM, "Blaine Cook" <rom...@gmail.com> wrote: > > Yes. Phishing is a problem. OAuth doesn't solve the problem of people > providing their login credentials to malicious 3rd parties. I'm pretty > sure that's in the Security Considerations section of the spec. > > To put a stronger point on it: Phishing isn't a technologically > "solvable" problem. Until people learn to properly identify safe sites > versus malicious ones (or trusted sites that lose credentials or store > them in insecure ways), phishing will be a problem. We can reduce the > number of points of contact with credentials, and we can try to make > it easier to understand when a site is trust-worthy versus when it is > not (via interface design, etc), but we can't stop people from doing > stupid things. > > Irrespective of OAuth, OpenID, SAML, or one-time tokens, I can put up > a "yourbank-noreally.com" site, ask for your birthdate, bank account > number, bank card number, verification code, one time password, etc., > and if you're really stupid, you'll enter it, and I can walk into a > bank with that information and steal your money. Once we stop looking > for technological solutions to social problems, we can make real > progress on helping people to use the web in safe ways. > > b. > > 2009/9/29 James Wanga <jwa...@gmail.com>: > > > > I'm new to the OAuth pattern, as such, I welcome any criticism of my > > > ignorance. As I understan... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
