OpenIDTeaching users to be secure is a shared responsibility
Ryan Janssen: Why an OAuth iframe is a Great Idea.
The reason the OAuth community prefers that we open up a new window is that if you look at the URL in the window (the place you type in a site’s name), you would see that it says www.netflix.com* and know that you are giving your credentials to Netflix.
Or would you? I would! Other technologists would! But would you? Would you even notice? If you noticed would you care? The answer for the VAST majority of the world is of course, no. In fact to an average person, getting taken to an ENTIRELY other site with some weird little dialog floating in a big page is EXTREMELY suspicious. The real site you are trusting to do the right thing is SetJam (not weird pop-up window site).
I posted a reply comment on that post, but I’ll replicate it in full here:
Please, please don’t do this.
As web developers we have a shared responsibility to help our users stay safe on the internet. This is becoming ever more important as people move more of their lives online.
It’s an almost sisyphean task. If you want to avoid online fraud, you need to understand an enormous stack of technologies: browsers, web pages, links, URLs, DNS, SSL, certificates... I know user education is never the right answer, but in the case of the Web I honestly can’t see any other route.
The last thing we need is developers making the problem worse by encouraging unsafe behaviour. That was the whole POINT of OAuth—the password anti-pattern was showing up everywhere, and was causing very real problems. OAuth provides an alternative, but we still have a long way to go convincing users not to hand their password over to any site that asks for it. Still, it’s a small victory in a much bigger war.
If developers start showing OAuth in an iframe, that victory was for nothing—we may as well not have bothered. OAuth isn’t just a protocol, it’s an ambitious attempt to help users understand the importance of protecting their credentials, and the fact that different sites should be granted different permissions with regards to accessing their stuff. This is a difficult but critical lesson for users to learn. The only real hope is if OAuth, implemented correctly, spreads far enough around the Web that people start to understand it and get a feel for how it is meant to work.
By implementing OAuth in an iframe you are completely undermining this effort—and in doing so you’re contributing to a tragedy of the commons where selfish behaviour on the behalf of a few causes problems for everyone else. Even worse, if the usability DOES prove to be better (which wouldn’t be surprising) you’ll be actively encouraging people to implement OAuth in an insecure way—your competitors will hardly want to keep doing things the secure way if you are getting higher conversion rates than they are.
So once again, please don’t do this.
I hope my argument is convincing. In case it isn’t, I’d strongly suggest that any sites offering OAuth protected APIs add frame-busting JavaScript to their OAuth verification pages. Thankfully, in this case there’s a technical option for protecting the commons.
Update: It turns out Netflix already use a frame-busting script on their OAuth authentication page.
I really can't bring myself to argue against usability. Browsers are where this problem needs to be solved. OAuth is nowhere near a good enough solution to justify its inconveniences. At least it's not as bad as OpenID though.
Is there a Security Working Group tasked with getting this fixed at the browser level? If not, why not. You're tilting at windmills here.
James Wheare - 16th July 2009 21:42 - #
Isn't this problem already solved by "remember this password" feature in most browsers?
Just create a different password for each site. Heck, you don't even need to remember it, just type a load of random characters into the password field and then get the browser to remember it.
If you ever forget, you can always reset via email anyway.
Charles Darke - 16th July 2009 22:45 - #
This is a great reply Simon. As a technologist and member of the Identity community, I also greatly sympathize with it. I'm still on the fence about this though. In fact, I thought about writing a follow up post on why implementing OAuth in an iframe is actually better for security. Here's my reasoning, and it is only half warped by my desire to give my users an easy experience.
If I (and the community) consistently redirect people to other sites, it is at least plausible that users would find this the "normal" way of doing things and look suspiciously at framed implementations (as they should). But realistically speaking, what would the user find "normal"? The answer--going to an entirely other site that LOOKS like their trusted site and typing in their credentials. The thought that they will pay any attention to the URL is a total pipe dream.
So where does this leave the user? Perfectly setup for every phishing attack in the world! On the other hand, with an iframe implementation, what does the user think--I'm trusting THIS site (the relying party) with my authentication credentials. And this is EXACTLY the site the user should be making the security evaluation about.
Now the community may argue that this defeats the purpose of OAuth and is no different than the user handing out their credentials to the relying party. It's not though--because I'm NOT storing the user's credentials. I'm not doing this because I, as the relying party, understand that this reduces MY risk exposure.
So my point is three-fold:
Redirects may not be teaching users what you think and may actually be teaching them to erroniously believe that when a site looks like their trusted that it is actually is their IP. By authenticating on the RP site, users are making the trust evaluation about the correct site.That all is not lost with this implementation because we've won half the battle by teaching TECHNOLOGISTS how to be an RP and the advantages on NOT storing user credentials.
Ryan Janssen - 16th July 2009 22:54 - #
Btw... Richard Lynch had a very simple but smoking good compromise. We're going to use the following copy:
You need to let Netflix know that you want to use SetJam:
If you've already got a Netflix account <login here>.
If you don't have a Netflix account, <start your 30 day free trial here>.
[smaller] We won't store your Netflix login information, but if you'd prefer to enter your login information at Netflix, click here.
This way the education piece is baked right in.
Ryan Janssen - 17th July 2009 00:09 - #
I'm pretty sure we have frame-busting JavaScript on the Netflix oAuth page, Simon; I pushed it myself, in May.
Thanks for stepping up, though. I agree 100%, and will be happy to argue security and privacy against usability.
The pop-up window is fast establishing itself as the good UX solution here.
Previously I advocated a sometimes-iframe, whereby the service provider allows their auth screen to be framed if (and <em>only</em> if) the user is already logged in to their service. That way, no passwords are entered into third party chrome.
— http://benward.me/blog/oauth-flow
In practice, the pop-up routine works almost as well, maybe slightly less slick, but also more consistent.
Advocating an iframe-only solution seems extremely problematic.
Good points, Simon - and I agree that some of these things would be better handled by the browsers, but we have to deal with the current reality.
The whole struggle between usability and security reminds me of political debates over liberty and security - neither will be solved easily or lightly.
By the way, major kudos for using the word "sisyphean" in a blog comment. :)
theharmonyguy - 17th July 2009 05:07 - #
Trouble is, exactly as Ryan argues, the non-iframe solution doesn't provide any extra protection. I've sat through openid and oauth login sequences with friends and family, and my impression is that the only thing the full-screen version does is provide a jarring experience for the user.
The people who are likely to be targets for phishing are not those who would be knowledgeable enough to benefit from the "look at the url" protection. I applaud the attempt at increased security, but I think believing the non-iframe affords actual real-world benefit is a fallacy.
I'd love to be proven wrong though.
Parand - 17th July 2009 10:23 - #
Charles: Even if browsers synchronized wand information between your trusted computers this wouldn't solve the problem completely; the first time you want to log on using a friends computer you're back to square one. And you can't actually believe normal users will adapt this practice. OpenID isn't perfect, it's just much better.
Hopefully browser vendors are looking into OpenID's phishing problem, and while we're waiting user education could be a temporary solution.
Parand: right now, most people have only a fuzzy idea of what a web site is, and no clue when it comes to URLs, domains, HTTPS etc. But that doesn't mean we should make it completely impossible for them to protect themselves.
Understanding those things needs to be like knowing to look both ways before you cross the street - people are going to have to become at least vaguely internet literate if they want to avoid having all of their assets stolen by online fraudsters.
Like I said, it's a sisyphean task - but what other options do we have?
I don't think this is an issue of user-education, what's causing this to be inherently insecure is that the pro-active party in creating the relationship between the two sites is the untrusted site.
Transplanting this model outside of the web, we're effectively going up to someone and telling them "Hey, I'm totally a business partner of your bank. Just tell your ATM card number to the person I'm talking to on my mobile phone and we can get working!" Saying that users should be educated in things like URLs is (to continue the non-web analogy) like saying they should recognise their banker's voice through a mobile phone - even in the unlikely event that fraudsters never learn to impersonate your banker's voice, you've still taught the user that it's ok to give their ATM card number to a stranger over the phone.
To make the process totally secure, the authentication process needs to begin with the already-trusted provider. Whether this means using some kind of OAuth/OpenID browser extension or toolbar, or going the route of your OAuth/OpenID provider having some kind of App Store style approved list I don't know.
Mark Hurrell - 17th July 2009 12:57 - #
Interesting line there:
"your competitors will hardly want to keep doing things the secure way if you are getting higher conversion rates than they are"
You're advocating reducing conversions for the sake of the general good. I had this argument with a client last month - and lost hands-down.
I think he was right - dropping a percentage point can be significant money.
I get the idea that this is a gesture towards the "right" thing to do. And the right thing is for browsers to do something. Where's the proposal for how that would look? Where's their incentive?
In the meantime, we're popping windows of openid providers asking if you can "trust" the original application. Perhaps we need to concede that either that trust extends to allow an iframe, or that you shouldn't be trusting that site anyway.
Sorry, but I think we've lost this one already. :(
Kenneth Kufluk - 17th July 2009 16:10 - #
Last I checked, people seem to be able to use PayPal all right, even though it employs those horrible, user-confounding redirects. Obviously we need to stop educating users about Web safety (which should be easy, seeing as how we never started) and start educating PayPal developers on the superiority of the iframe.
Seriously, though, if iframes really provided a better user experience and, as Ryan argues, heightened awareness to phishing, wouldn't PayPal switch to it in a second? I can't think of many sites where an improved UX more directly translates into cash or that have more incentive to protect their users from phishing than PayPal. So why not? Users aren't going to check the URL anyway, right?
Wait, what's that? You wouldn't in a million years use PayPal (or any similar service) if it used iframes? In fact, you'd warn your family and friends not to use it, too?
So what's the difference between using an iframe to ask for the user's PayPal credentials and using an iframe to ask for the user's Netflix credentials? Nothing, since for many people the two sets of credentials are identical.
But I guess we shouldn't bother educating people about the dangers of using the same password everywhere, either.
Joel Bruick - 17th July 2009 18:23 - #
Yes, I am.
Thankfully, we haven't. Frame-busting JavaScript means iframes aren't a workable option.
I still remember Lisa Dussault being fairly against OpenID because of it's reliance on forwards and phishers love to create sites that looked legitimate but aren't. I still think if OpenID became hugely popular it would be a new breeding ground for phishing.
The one secure federated ID solution Lisa used to hold up was one from Microsoft that actually locked the application and made you login in a new OS level window.
Verisign built a Firefox extension to do nearly the same thing in Firefox for OpenID.
https://pip.verisignlabs.com/seatbelt.do
This seems to be the only truly secure solution for OpenID and does require a certain amount of browser support from each vendor.
mikeal - 17th July 2009 20:52 - #
Using the web without understanding URLs is like handing your credit card to anyone who looks like they might be a waiter.
I understand that most people don't understand them, but that's no reason to avoid teaching them.
Jeremy Dunck - 18th July 2009 00:27 - #
Couldn't agree more, which is why I was surprised when a post from your feed came into Google Reader titled, simply, "Why an OAuth iframe is a Great Idea."
Not trying to pick nits here, but it occurs to me that you're a very influential character, and I wonder how many folks just followed that link, assuming you endorsed it.
Kevin: did it show up without my strongly worded rebuttal in the description? I frequently link to (or even quote from) things I disagree with, not sure what I can do to avoid the idea that I'm endorsing them.
Yah, the description was there. Not sure what you could do about that perception either. Maybe it's a non-issue, but it just struck me, which is why I commented.
I think as web developers we all have a shared responsibility to educate users and clients on internet safety. Your average internet user has not been educated on SSL. Certificates and URL- Redirecting ect. I would love to see internet security tought in schools in IT classes, a simple one hour lesson would be enough to teach the basics to our next generation in schools
Wonderweb Media - 21st July 2009 19:30 - #
I agree with Charles Darke !
I think we have to teach them other security attitudes.
Many internet users are not accustomed to OpenID or OAuth :(
djerba - 2nd February 2010 20:53 - #