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 <[email protected]>: > > I'm new to the OAuth pattern, as such, I welcome any criticism of my > ignorance. As I understand it, Section 6.2.1 of the OAuth 1.0a spec > states that the consumer MUST obtain approval by directing the user to > the service provider at which point the user enters their credentials, > consequently, approving the request token. From what I gather, this > redirection serves two purposes. It keeps the users credentials safe > from a malicious/careless consumers and it prevents anyone snooping > the wire on non-SSL connections from obtaining any useful data. I > think premise that a redirect to the service provider keeps > credentials safe in any reliable way is deeply, deeply flawed. I've > read several arguments issuing caution about the susceptibility of > this pattern to phishing attacks and most just issue the warning then > continue on to explain how to implement it anyway. In my humble > opinion a phishing attack is so trivial with this pattern that > attempting to keep user credentials from the consumer is futile. > > Let me use the canonical scenario. The consumer - printer.example.com > - directs the user to the service provider authorization page - > photos.example.com/authorize - where the user logs in and authorizes > the consumer. The OAuth pattern argues that this keeps the user safe > in the event that printer.example.com is a den of thieves interested > is stealing your credentials. I disagree. If they wanted to steal your > info it would be pitifully trivial to redirect you to > example.printer.com/authorize. The idea that most users will notice > the URL slight of hand is unrealistic. Did you? For that matter, a > malicious consumer could load the authorization page in a browser > window without an address bar and remove the users ability to tell the > difference. The only benefit redirection seems to offer is in keeping > consumers from carelessly storing passwords that can be stolen. If a > consumer wants your password, they'll get it. Easily! > > I argue that it is so easy to trick large numbers of users with a > fake authorization page that the requirement is useless. Though far > from ideal, I propose that it isn't any less safe to allow the > consumer - web or installed - to authorize themselves by prompting for > the users credentials and passing them over SSL. This would still > eliminate the need for the consumer to store credentials on the users > behalf as with basic auth and it would spare users the unfamiliarity > of the OAuth workflow. I realize this does nothing to control > malicious consumers. My only case is that compromising the redirect > workflow is so trivial that at least we can give the user back a > normal authentication experience. > > Once again, it is entirely possible that I'm mis-understanding > something, it wouldn't be the first time. But if I'm not, then we > should really consider whether or not redirection is presenting a > dangerous, false sense of security. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
