Dready blog writes about OpenID phishing and proposes a browser plugin that introduces a delay in the dialog box before it can be dismissed.
“The OpenID phishing issue is a hard one to solve, particularly because it aims to:
- be user-friendly, i.e. it should pass the mother-in-law test; and
- work on the web platform without special software or browser plugin
“So, why is this suddenly a problem?
“Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You donâ€™t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like â€™shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.”
Actually, the problem is worse than the one we currently face. We are not just dealing with “the perennial problem”. If you use one OpenID account to go to two hundred sites, the thief who steals your OpenID credentials gains access to any of the 200 sites. That's new.
“This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesnâ€™t match your OPâ€™s, you bail out. Doesnâ€™t that sound simple? Well, the cold hard fact is that phishing works and there is research1 to prove that people get tricked very easily.”
Dready's right about the research. But rather than calling it a “social problem” I'd call it a “social engineering attack”. Further, there is a protocol problem. The protocol is based on telling the RP where the OP is located – such that an evil site can automate a “man in the middle attack”. Some other protocols, including the one used by CardSpace, do NOT have this problem. That's why combining CardSpace and OpenID is useful.
“Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:‘Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.
'This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.’
“The picture is not so sunny, however, because most users:
- wonâ€™t know / bother to install specialized plug-in or upgrade their browsers unless theyâ€™re forced to
- wonâ€™t know the difference between citibank.com/signon and citibank.com-banking-foobar.com
“And even if they installed those anti-phishing toolbars and what not, they still fall for it!
“While I canâ€™t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just donâ€™t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions â€” Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I canâ€™t click so I might as well read a little.” (Code follows here…)
This may help Dready and in that sense it may be a welcome finger in the dike. But as OpenID becomes successful and is used for sites of value, this kind of solution clearly won't stand up to attack or scale to embrace the population.
People really need to think about what it will mean to actually have “single signon”, rather than just talk about it.
You cannot overestimate the value of your single signon credentials, or the extent to which they will attract attack.
I don't think browser-based solutions will do anything for us long term – the whole point of browsers is to make it easy to introduce cool new behaviors and empower the RP to give the user great experience. They are vulnerable because they put the RP in control – by design.
This doesn't mean plugins can't play a role in getting us to our destination. But ultimately, you need defense in depth, many layers of defense. If we think of the browser as a “broadband communications channel” inundating the user with information, we also need a “narrowband communications channel” honed to protection of the user. The CardSpace work represents an attempt to create this.
4 thoughts on “Can browser-based plugins solve OP phishing?”
Dready is actually Wil Tan, primary maintainer and main contributor to OpenXRI.
BTW, this is the first time I've ever actually used Cardspace to authenticate (through Firefox, no less – though there were some hiccups).
On a slightly different note: Have you had a look at the beta release of Windows Live ID SDK? Boy, that thing is scary. Essentially they encourage ISVs to write smart client apps that show a login dialog that looks exactly like the one Windows Live Messenger uses to then access some of the Windows Live services. So, if the proceed, user will get used to download windows apps that show dialogs that ask for Windows Live ID credentials. With absolutely NO way to tell what they are going to do with them. To me that is scary, scary, scary. Plus I don't understand why they don't use Cardspace for that scenario.
I would be more than interested to hear your comment on their approach. And maybe you can stop that thing before it goes RTM and does lots of damage.
Comments are closed.