Scott Kveton

Phishing and OpenID

Note: with IIW starting today, I thought it would be fitting to talk about phishing and hopefully also convene a session on this over the next couple of days. This is a big problem for us in this space and something we’re going to need to find a solution for.

The second most common request from potential adoptees of OpenID (right behind having a solution to the potential spam bot problem) is, what is the answer for dealing with phishing of OpenID’s?

Phishing to me is one of those “The Internet Sucks ™” problems (another example is how easily DNS can be spoofed – yes, its a bummer, but how do you *really* fix it?). However, I believe there are a few things we can do with OpenID to help alleviate the problem. After all, with one username and one password for all of the sites you visit in in one place, the stakes are much higher.

The one thing we have going for us with OpenID as it relates to phishing is that users will be developing a stronger relationship with the one site that they enter in their password at. If there is even the slightest problem, it will be more obvious to the user because they go to their identity provider so often. Users are getting more and more sophisticated and the early adopter crowd is extremely savvy when it comes to phishing. However, this isn’t good enough.

There are a couple of approaches you can take to deal with phishing:

Personalized site seal: Yahoo! has recently launched a service that allows users to put a personal image that they have chosen on their login page. If the user is directed to a phishing page that doesn’t have that picture on it, the user will realize it immediately and hopefully not enter their credentials. I’m not sure what they have done to make sure you can’t scrap that image from the users’ login page but I think this is to help stop against “general” phishing pages. We’ll be implementing personalized site seal functionality in our OpenID identity provider soon.
Two-factor authentication: What about having more than just a username and password? The example would be of a user having to enter in both a username and password, authenticate and then enter in some other data such as a secret question or contents of an SMS message. The phishing site might get your username and password but they won’t know your secret question. Feasibly, however, they could directly “log you in automatically” to your identity provider and then scrap the question but this too would be quite difficult althouhg unfortunately not impossible.
Browser extension/plugin: My least favorite of the solutions is to use an extension or plugin on the client to help verify the users’ identity provider. When installed, the user would enter where their identity provider is. If the user is presented with a username/password field that is not at their identity provider, it would change the chrome to red on the browser or bring up an annoying popup (it has to be annoying to be effective). Andy Dale has a great Firefox extension for doing this for OpenID’s and I believe Sxip is also working on one as well.

Unfortunately, that’s all I’ve got. Its not fantastic and none of those completely stop the problem, they just buy us time while we figure out better solutions. If you have ideas for ways to combat phishing with OpenID’s, by all means, please comment here.

About The Author

kveton

4th

December 2006

bykveton
posted in JanRain, OpenID, Phishing
16 Comments »

14 Comments Add Yours ↓

The upper is the most recent comment

Vincent #

12.05.2006 14:37
1
My bank’s approach to combat phishing seems pretty good.

1. Enter your username.
2. Answer a secret question.
3. Enter your password on a screen which has an image and phrase that you selected when you set up the account.

This is a bit much for logging in every time, so they set a cookie once you have succesfully logged in. From that point on, on that particular computer, you just do steps 1 and 3. If you clear your cookies or go to another computer, you get to answer the secret question again.
http://xenomouse.livejournal.com/ #

12.05.2006 17:04
2
I was wondering about this earlier, and those are some very good suggestions. I think the personalized site seal is the best suggestion of those three. One thing in which i would have more confidence is to be logged into the OpenId provider before trying to access a site that supports OpenId. As long as the provider is stateful (and your session is still alive), you should never need to provide your credentials when validating. However, for stateless servers, the seal is definitely the way to go.
court3nay #

12.12.2006 01:13
3
Display three images on the login page.

One of them is your image, selected earlier, the others are random, or just other people’s image. This combines 2-factor login with captcha with site-seal.

The weakness is that refreshing the page will give you different random images, so it’s easy to determine the real picture.. except.. if there’s only a pool of 10 images, or, the random items don’t change..
Dmitry Shechtman #

01.12.2007 16:49
4
How about external authentication?
kveton #

01.12.2007 18:19
5
To save people a lot of reading, external authentication means using out-of-band methods like IM, email, Skype or others with a one-time-password. This is a great idea.
thomasmaloney #

01.13.2007 02:22
6
I don’t think site seals work. A spoof site can pass whatever username / password / shared secret to the real site and present the site seal back the user.

As far as establishing the identity of an IdP or any site, an EV SSL certificate is probably the best solution to date. Adoption of EV SSL is another story (I believe the current and first EV SSL standard to be decided on took around 1.5 years.)
kveton #

01.13.2007 17:14
7
Thomas: actually the site seal is not tied to your username and password. Its a one-time setup between your computer and the identity provider. The attacker would have to have access to your machine or in the case of a non-SSL connection, do a MITM attack. Looking over the general OpenID list archives, folks are saying that the Yahoo! site seal has some Flash functionality … if you setup the site seal on Firefox its there on IE as well.
thomasmaloney #

01.13.2007 17:54
8
I’m pretty sure the site seal is tied to cookies.

I setup the Yahoo! site seal in Firefox. When I went to login in Safari, the seal was not there. Once in Safari, I logged in, logged out, and when logging back in a second time the site seal was not there.

Going back to Firefox, I deleted the Yahoo! cookies while signed out. When signing in, the site seal was not there.

I’m not sure how I feel about that. I read somewhere that a lot of people delete cookies nowadays.
Don Park #

01.16.2007 22:32
9
If you guys are referring to BoA’s SiteKey which uses PassMark technology, cookies and other mechanisms are used to profile the client’s computer, network, and user for real-time risk analysis as well as offline risk analysis. Also, on-demand out-of-band authentication may kick in when risk gets too high. Overall, I think it’s an effective anti-phishing solution. But then I could be biased since I am one of the guys who built it.

Frankly, I think the best way to protect passwords from phishers is to hide the password from the user because you can’t lose what you don’t have.
Kisakookoo #

01.23.2007 18:42
10
Hi! Why I can’t fill my info in profile? Can somebody help me?
My login is Kisakookoo!
kveton #

01.24.2007 06:37
11
Where can you not fill out your profile? MyOpenID.com? More than happy to help.
kveton #

01.24.2007 14:53
12
FYI – we’ve implemented two new features on MyOpenID that help fight phishing as per suggestions from the OpenID community.
Acura #

10.07.2007 22:06
13
One thing in which i would have more confidence is to be logged into the OpenId provider before trying to access a site that supports OpenId.
Steve Pepple #

02.13.2008 18:41
14
To try to solve the problem using two-factor authentication, a team I work with is developing a beta implementation of strong, multi-factor authentication for OpenID,
TrustBearer OpenID.

We’ve been concentrating on simple user experience at this point, and we are interested to learn what sort of features user will look for in this type of implementation.

With our OpenID, you basically just set-up a strong authentication device
and then link the device to your OpenID URL.