In the last months OpenID definitely gained momentum. Everyone is running to provide support and integration. But what about OpenID phishing risks?
It’s undeniably true that OpenID makes life easier to phishers: they no longer have to mimic PayPal or your bank site, but simply build an appealing and innocent website and get you to login using your OpenID. Then, following the protocol, they can discover your OpenID provider and direct you to their fake login page that will look exactly or almost exactly as the original one. You type in your password thinking that you’re safe, but in fact you’re giving out your details to a rogue third party, who now can use it across all of your registered sites and services.
The OpenID protocol is designed in such a way that these traps can’t be avoided, and the new draft does nothing to mitigate this risk. So the burden is shifted to identity providers and users, in the perennial game of externalize security costs …
While Simon Willison ask for “client-side plugins and direct support from browsers”, Tom Coates on Plasticbag.org honestly says:
In the end - if [OpenID] is to take off - I suspect this problem is going to be solved by a combination of design and education. People are going to have to get their heads around web addresses a bit more. Or we’re going to have to build something into browsers that handles distributed identities a bit more effectively.
To date one of the most popular OpenID provider, MyOpenID by JanRain, is very proud of the following countermeasures: a picture of your choice to be uploaded in order to build a more familiar and less replicable login environment, a warning page displayed before landing to your login page. Phishers beware!
I really appreciate the position of Ben Lauries that has been constantly and positively engaging in discussion the OpenID community about the increased risk of phishing.
Phishing needs security between the identity provider (OP, actually, in OpenID parlance, I wish they’d be consistent) and the user.
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. In an ideal world, this would be a standard component of browsers, but it isn’t. Why? Well, the reason is fairly apparent: the best general way to handle this problem is through zero-knowledge proofs. SRP is an often-quoted example, but there are many simpler ones. However, various (already rich) greedy bastards have successfully blocked wide deployment of these protocols in a cynical attempt to profit from patents that (allegedly) cover them
He’s right! And Ben, your fervor reminds me of Tom Wu and his answer to my question about the relative success of SRP:
SRP in effect cuts out the middleman and allows direct user authentication without expensive infrastructure to secure that initial connection before sending the password. It is understandable and commonplace that corporations that sell a product would be opposed to alternatives that eliminate the need for that product, even if the alternative is a net win for the end user. In past years, implementors were concerned about strong password protocols because most of them had patent restrictions, but because SRP has a well-established free license, those concerns have fallen by the wayside and SRP can move on to the next phase.
Verisign involvement in OpenID did not initially raised many suspicions, and I’m afraid it’s too late now …
A simple solution
You can protect yourself against this risk by choosing an OpenID Provider that takes a security token other than a username and password. One idea already suggested is Windows CardSpace cards. A certificate of any kind would completely eliminate the danger of credentials being stolen by a site posing as your OpenID provider.
Ok, but ...
Andrew, it’s true that each OpenID Provider could implement different authentication protocols, but as of today I’m not aware of anything with really strong anti-phishing features. Do you have some name?
Windows CardSpaces have definitely some appeal, but I think they will not help much (yet) in a world where I would like to login to my web services from a public terminal, my mobile phone, my friend’s MacBook, …
Marco
I personally can
I personally can’t wait for the first OpenID provider with strong anti-phishing mechanisms, be they client-side certificates or CardSpace or some kind of other plugin. In the meantime, there are steps that existing providers can take to reduce the risk of phishing such as the ones MyOpenID implements. If you have any good ideas, join the OpenID community and share them! That’s what Ben Laurie has offered to do: http://www.links.org/?p=188
Short term goals
Simon,
I’m not saying that your efforts (and those of Scott Kveton, Bel Laurie, …) are useless. On the contrary!
I’m just convinced that, in the short term, there are other ways to achieve a better login experience.
My vision, and the whole Clipperz project, is about exploiting Ajax and browser cryptograhy to build a secure online password manager.
I’m aware that it’s a limited goal and that I’m following an unpopular path, but I think Ben Laurie is perfectly right when he says “You need better client-side software.” We are trying to build better software within the browser itself, to date the most popular piece of software …
OpenID is really a fascinating project, but I still prefer to investigate methods that give the user full control of his/her personal data without the need to trust a third party. And cryptography on the client-side is the way to go!
Regards, Marco
What about the rest of us?
I eagerly signed up for an OpenID once I appreciated what it was trying to achieve. But because of all the talk about the phishing risks, I’m now worried about using it anywhere! (clarification: I really do appreciate learning about all the phishing issues!)
So until we get these client-side tools and stuff, what can Joe Blow like me do to protect their OpenIDs?
Do not re-use your OpenID password
@Rene
My advise is to never re-use your OpenID password!
To date OpenID is supported by websites that are not providing critical services and usually they do not handle very sensitive information about you (e.g. blogs, forums, social bookmarkings, …) so you don’t need to be paranoid about this password.
For all other services choose strong passwords, a different one for every different website. A good password manager will help you to generate and store those passwords.
Cheers, Marco
Thanks Marco!
Thanks Marco! From your reply to Mr. Simon, I gathered you’re working on client-side password management via some browser add-on. Would be willing to be in your Beta if that’s how you’re planning to go!
Best - Rene
Access granted!
Rene, you will soon receive (2/3 weeks) an invitation code for our private Beta.
In the meanwhile you could take a look at the Javascript Crypto Library. It’s a first release but it could come handy if you are planning to add “browser based” encryption capabilities to your web apps. It’s an open source project and any contribution is welcome!
Thanks for your interest, Marco
making openid unbreakable is possible
my newest app: http://prooveme.com solves the openid security problem by adding strong authentication, namely client certificates, to openid.
At the moment it only works in firefox and other netscape derived browsers (camino definitely works!) but we are adding support for IE. It’s just that IE has very complicated certificate support.
There’s nothing that can be done to break a prooveme.com id except DNS poisoning and any security system (SSL, kerberos, etc…) is vulnerable to that.
not only certificates
first, prooveme just works perfectly and I'm using it happily :)
Another service that permits to login with certificates is certifi.ca, which allows you to use many different kind of CA.
And even if you don't want to use certificates you can still use anti-phising systems based on personal informations stored in the relaying party, like yahoo! does now.
But even in openid-land there is already who is doing this, for example idproxy uses the simple but efficient MonsterId system.
err...
well, I think without explanation that seems useless and unrelated, but the point is to have a shared secret with the provider, in the form of a dummy image (see yahoo!’s sign-in seal for a better implementation)
Sorry for posting too fast :)
prooveme looks interesting
prooveme looks interesting but doesn’t using a client side certificate mean that you can only use browsers with that certificate installed? Do you think most people know how to install, transfer, protect their certificates?
If they loose their certificate I assume replacement could be done by logging into prooveme using an alternate method. Wouldn’t this alternate method be the weak link?
Can't have it both ways!
Discussions like this are always a “headdesk” moment for me.
The discussion so far: - OpenId is cool! - Yeah, but somebody could phish a login! - Well, you can use a client cert instead - Yeah, but thats too complicated for users; they don’t want to install client software!
So the solution is…. a password manager installed on the client?
I really don’t understand how pressing “Accept Certificate” in a browser (IE or Firefox or derivates) is more complex then downloading and installing an “exe” or whatever.
As for the phising: The basic premise of OpenId is that the USER is in control of the security level he wants. You want a simple username and password? Ok. You want a juggling monkey that randomly accepts request? Ok too?
Or do you want a totally secure client cert that is linked to a secure https cert, which cannot be faked, even with DNS poisoning? No problem!
Or do you want to authenticate with separate secure hardware device that takes a PIN and outputs a one-time access number? No problem, you can get one for less than the price of a big pizza at Paypal or Verisign.
I would also like to point out that currently the OpenId provider I am using has a higher security level than the bank I am using.
Makes you think, no?
Closing remark: OpenId also has some good solutions that do no require captchas.