I completely agree that checking URLs isn't the best possible defence, because, as you mention, how many users actually check the url? Unfortunately, at the moment, it's the only thing that is effective 100% of the time. I think it's better than it was... awareness about phishing scams and malware sites is slowly training users to be more diligent in this regard.
I love the idea of browsers issuing warnings if a user is visiting, for the first time, a site claiming to be an OAuth SP. I think browsers could do a lot in this regard and it'd be a huge sign of success for this community to see them take this kind of thing up. Maybe support for maintaining a whitelist of OAuth SPs that the user has accounts with. If the user is redirected to a site they haven't whitelisted, the browser can present them with a subtle warning asking if they're sure they want to give their credentials to an unknown party (maybe the user knows what they're doing... maybe they've recently cleared their browser data, etc). An obvious question is, how do we push browsers in this direction? What can be done to encourage browsers to treat previously unseen OAuth SPs in a similar way that invalid SSL certs are treated... or as you mention, bad-site iframes. Cheers, Paul On 2010-01-18, at 10:31 AM, John Panzer wrote: > Devils advocate: I know all of the arguments pro URL bar. Note that > even without that, the browser will issue warnings if iframe'd over to > a known-bad site. At least modern browsers will. I suspect those > warnings are far more effective, when they trigger, than users > checking urls. Perhaps browsers can do more - a subtle clue about > phishing today is that your password field is not prefilled; could > they be more blatant? Issue warnings for entirely new sites the user > has never seen that claim to be OAuth SPs? > > How many users actually check urls? How many are equipped to check > urls with Unicode characters? > > Would it be possible to get 99% of the security with an iframe plus a > button to pop out to a full window to complete the action? The latter > would be chosen by a self selected group of people who actually check > urls and are potentially giving up a high value password. > > And, it'd be far more usable, letting more sites abandon the > collect-the-password antipattern, leading to better security overall. > > On Monday, January 18, 2010, Paul Osman <[email protected]> wrote: >> Hi Willem, >> >> While it's obviously not something that is covered in the spec (User-Agent >> specific details are understandably out of scope), I would say that it is >> strictly necessary. It gets into the "spirit" vs the "letter" of a >> specification. In my view, using a browser and hiding the location bar >> breaks the spirit of OAuth and makes the user authorization step less secure. >> >> True, users can always view the location of the page through the properties, >> but why introduce that hurdle? What percentage of users will know to check >> that? >> >> As Chris mentioned in another reply to this thread, there are two pieces of >> information that a user must have: >> >> * the URL where they're entering their password >> * whether the connection is secure (ie using SSL) >> >> The best way to communicate this information in most browsers is the >> location bar. >> >> Anything that obfuscates the source of the authorization screen, in my >> opinion, breaks an OAuth implementation because it interferes with a users >> ability to identify critical pieces of information (the URL and the security >> details of the connection). >> >> Cheers, >> Paul >> >> On 2010-01-18, at 5:13 AM, Willem Jan Gerritsen wrote: >> >>> Hi, >>> >>> A user can always view the location of a page through the properties. >>> Being able to view the URL in the location bar is useful, but is it >>> strictly necessary? >>> >>> Regards, >>> Willem Jan >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Paul Osman >>> Sent: Sunday, January 17, 2010 5:12 PM >>> To: [email protected] >>> Subject: Re: [oauth] Best Practice >>> >>> If the user cannot reliably see who is presenting the authorization-sign in >>> window, they have no idea who they are giving their credentials to. This >>> makes the whole point of delegated authorization moot, so I would consider >>> it absolutely necessary to direct the user to a browser window where the >>> location bar is visible. >>> >>> Cheers, >>> Paul >>> >>> On 2010-01-17, at 10:17 AM, eco_bach wrote: >>> >>>> Hi >>>> Building a Twitter application using OAuth. >>>> I'd like to embed the Twitter OAuth authorization-sign in window >>>> WITHIN my application. >>>> >>>> Is this considered a best practice, or is it always recommended to >>>> send the user to a new browser window for the service provider(Twitter >>>> in this case) authentication process? >>>> -- >>>> 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. >>>> >>>> >>> >>> >>> The information contained in this communication is confidential, intended >>> solely for the use of the individual or entity to whom it is addressed and >>> may be legally privileged and protected by professional secrecy. Access to >>> this message by anyone else is unauthorized. If you are not the intended >>> recipient, any disclosure, copying, or distribution of the message, or any >>> action or omission taken by you in reliance on it is prohibited and may be >>> unlawful. Please immediately contact the sender if you have received this >>> message in error. This email does not constitute any commitment from Cordys >>> Holding BV or any of its subsidiaries except when expressly agreed in a >>> written agreement between the intended recipient and Cordys Holding BV or >>> its subsidiaries. Cordys is neither liable for the proper and complete >>> transmission of the information contained in this communication nor for any >>> delay in its receipt. Cordys does not guarantee that the integrity of this >>> communication has been maintained nor that the communication is free of >>> viruses, interceptions or interference. If you are not the intended >>> recipient of this communication please return the communication to the >>> sender and delete and destroy all copies. >>> -- >>> 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. >>> >>> >> >> -- >> 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. >> >> >> > > -- > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > -- > 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. > >
-- 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.
