The valuable thing about being redirected back to the service provider is that there is a prior relationship that can be leaned upn to prove the authenticity of the service provider.
Currently most login pages are static and therefore scrapable. Phishers can reproduce your bank's login page on their own domain and it looks the same to the end user except for the address bar. FreshBooks took a different approach. The OAuth challenge pages are not static, but reflect the underlying account they are authenticating against. We have the advantage that we require the subdomain of the account (e.g. joesgarage.freshbooks.com), and thus we can show all the branding elements of their particular account: * System colours * System logo * Company name Admittedly, this is scrapable by a determined attacker. They would just have to scrape the OAuth page every time. We could thwart that by requiring all request token requests to have a valid consumer secret (we don't in the cases of desktop apps and mobile apps), and only showing the authorize page if we get a valid request token. Right now we're weak on that, but I'm interested in other ideas to strengthen ourselves in the case of no consumer secret. Cheers, Sunir Shah, Chief Handshaker, FreshBooks (416) 481-6946 x224 http://www.freshbooks.com/team/sunir http://twitter.com/sunir On 29-Sep-09, at 2:23 AM, James Wanga wrote: > > 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 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 -~----------~----~----~----~------~----~------~--~---
