get_col("DESC $table_name", 0) as $column ) { if ($debug) echo("checking $column == $column_name
"); if ($column == $column_name) { return true; } } //didn't find it try to create it. $q = $wpdb->query($create_ddl); // we cannot directly tell that whether this succeeded! foreach ($wpdb->get_col("DESC $table_name", 0) as $column ) { if ($column == $column_name) { return true; } } return false; } } function btc_altertable() { global $tablecomments; $sql = "ALTER TABLE $tablecomments ADD COLUMN comment_reply_ID INT NOT NULL DEFAULT 0;"; maybe_add_column($tablecomments, 'comment_reply_ID', $sql); } function btc_alter_comment($new_id) { global $tablecomments, $wpdb; $sql = "UPDATE $tablecomments SET comment_reply_ID=".$_POST['comment_reply_ID']." WHERE comment_ID = $new_id;"; $wpdb->query($sql); } function briansnestedcomments() { global $font_gets_smaller; if (!($withcomments) && ($single)) return; // You can safely delete the single line below if your threaded comments are up and running btc_altertable(); ?> Usable Security » Blog Archive » Phishing and OpenID: Bookmarks to the Rescue?

Phishing and OpenID: Bookmarks to the Rescue?

January 20, 2007 by Ping

OpenID, as currently used for single sign-on, facilitates phishing.

Using OpenID, you can establish an account at any identity provider you like, and then use it to log in to any OpenID-enabled website.  Unfortunately, the way it’s currently deployed, described, and demonstrated, OpenID makes users even more susceptible to phishing than they are without it.  That’s because the OpenID login procedure can look like this:

  1. Visit a site I’ve never seen before.
  2. Enter my OpenID name and click “Log in”.
  3. See the login form for my OpenID provider.
  4. Submit my password.

And the experience of being phished looks like this:

  1. Visit a site I’ve never seen before.
  2. Enter my OpenID name and click “Log in”.
  3. See the login form for my OpenID provider.
  4. Submit my password.

In other words, OpenID providers that redirect to login forms train users to follow a link from an unknown site and then enter their passwords.

Several people have now written about this problem; most recently Ben Laurie kicked off a long discussion on the OpenID mailing list.  Here’s an idea for how to deal with it, building on Simon Willison’s proposal.

One Possible Answer

Ask users to bookmark the login page.  Never show a login form in response to any request that contains a Referer: header.

The User Experience

Imagine a fancy new OpenID provider called “BookmarkID”.  It advertises that you should use it for authentication because it’s safer.

When you set up an account with BookmarkID, you’re asked to make a bookmark to the login page.  (You can either right-click on a link to add it to your bookmark menu, or drag the link to your bookmark bar.) With BookmarkID, you always use your bookmark to log in.  If the BookmarkID service ever needs you to enter your password, it will ask you to use your bookmark.

BookmarkID will never redirect you to the login page, and anyone else who tries to take you there will only bring up a big warning reminding you to Always use your bookmark to log in.

Cost to you: just one click on your bookmark (for the lifetime of your cookie).

Benefit to you: phishing resistance for all the OpenID-enabled sites you use.

Would You Use It?

The cost is not zero.  You have to do a little bit more to use BookmarkID.  So maybe it’s not for everyone.

In the most common case, your browser auto-fills your password, so it’s two clicks (bookmark and submit) instead of just one (submit).  But the tradeoff isn’t bad — after doing this once, you don’t have to do it again until the cookie expires, and you only have to bookmark one site instead of every website you use, because of the leverage that OpenID provides.

On top of that, keep in mind that we’re already asking users to adopt a new login procedure when they use OpenID — it’s a login procedure that requires at least one extra click, and we expect them to be willing to do that in exchange for the convenience of single sign-on.  Since we’re teaching users a new login procedure anyway, why not teach them a safe one? 

BookmarkID would be worth it to me.  I’d use it.

And the beauty of OpenID is that I can use it, and those of us who think this is worth it can use it, without forcing anyone else to.  Someone could just come along and launch the BookmarkID login service and see who likes it.  It could happen any day.  It could even happen tomorrow.  It could turn out to completely fail for reasons I haven’t thought of, and we could still go on looking for other solutions without having to migrate everyone off of OpenID.

I’d be grateful for your comments and thoughts on this.

I really like it. It’s similar to my proposal but much, much easier to understand - especially as the key security feature is described in the name of the service.

I’m always a bit skeptical of anything that involves checking the referer header due to some companies stripping it out at the firewall, but in this case I can’t see how that would cause any breakages.

Obviously someone else likes the idea too, because the domain names / .net / .org were all registered today.

(Comments won't nest below this level.)

Thanks! It really is your proposal. After I looked through the comments on your entry I realized this is essentially the same as what you and Nato were discussing there.

I registered the domain names. (This happens when I get excited about an idea, and this one seems fairly dependent on having a name that makes it impossible to forget that you’re supposed to use bookmarks.)


I really dig this idea. I’d use it for sure. Hopefully someone will take you up on implementing it soon!

(Comments won't nest below this level.)

The MITM attack allows the bad guy to modify any headers being sent to the real OP, including the Referer: header. An unsuspecting user will just type in their credentials as they will see the usual prompt, forgetting they are supposed to go to the OP via the bookmark. So unfortunately this solution is easily defeated.

(Comments won't nest below this level.)

Any solution can be defeated if you invent a sufficiently absentminded user.

This proposal is just a different point in the space of tradeoffs between variables like phishing risk, implementation complexity, ease of deployment, user attention required, and user effort required. It’s neither ideal nor terrible.

My hypothesis is that someone who chooses BookmarkID as their preferred method of authentication stands a better chance of remembering to use the bookmark than a typical user. This hypothesis is unproven, and could turn out to be false. But why not try it? OpenID lets us do experiments like this.

If user’s where not absent minded, then they would not get phished!

I don’t think we can experiment around people getting phished. The basis of your theory is the Referer: header is missing. This can easily be circumvented, disabling a key piece of securing the channel between the user and the OP.

No no — the basis of the idea is that people can be trained to use bookmarks. The Referer: header is merely a part of the training.

Okay, let’s continue this conversation on the mailing list instead of in both places. :)


Why a bookmark? Why not a special “Login button” built into the browser for this particular purpose? This is not “just another link.” It is something very special and should be treated as such.

bob wyman

(Comments won't nest below this level.)

This is aimed at existing unmodified browsers. Definitely, if you can add features to the browser, you can do better (e.g. Passpet or other extensions).


Ah, I’m not sure it’ll work. The problem is this:

I go to to, say, post a comment, and it has a “Sign in with your OpenID” box.

I type into the box “”, which is my OpenID, provided by the service, and click the “Sign in” button., unbeknown to me, redirects me to, which looks like, and says “OK, now click your bookmark” (just like the real bookmarkid does).

I click my bookmark, which takes me to, just as it’s supposed to.

Now, I’ve avoided being phished, which is good. However, I’m now at the front page of, and it has no idea that I was at So I’m stuck there. I can’t post my comment. can’t say “You were at an evil site; watch out!” because it won’t know. So I’m left hanging in limbo. That’s really confusing. You’ll give people this big sense of disorientation, which they can’t explain and can’t articulate.

Am I misunderstanding how it works?

(Comments won't nest below this level.)

I think you’re underestimating the power of the back button. It’s true this might confuse a bit but I reckon that the situation is going to be rare enough not to bother users too much - they’re gonna be pressing “back” until they can post their comment again.


I don’t think you’re misunderstanding it. The procedure I had in mind was to first use the bookmark to log in, and then retry the original transaction. With a little care in the UI, the provider might be able to make this less confusing.

Mark Fowler wrote:

A random thought:

You can use the bookmark as verification itself, i.e. if you can visit the URL then you are that person. Visiting the URL should be enough to log you in.

This prevents the user ever having to enter a password. Make it so the only way you’ll ever need to enter a password is when you go to the front page to sign up for a new account or request a new bookmark. This’ll train the user _never_ to enter a password when they’re asked for one. Ever.

(small note; You’ll want to make the url you give out for bookmarks https:// so they can’t be captured by proxies, etc)

(Comments won't nest below this level.)

Yes, you can embed the secret in the URL. Then you’re essentially using the URL like a capability. In general, this is a great idea, though it may take some catching up from software to properly treat URLs as capabilities (they need to be treated as secrets, and there’s the issue of logging in from a different computer than the one you normally use).


sil: that scenario is true, but I don’t see it as being a show-stopper. There are already loads of malicious sites that confuse users - I imagine they’re pretty used to wondering around the Web in a permanent state of bewilderment. Better confused than phished.

(Comments won't nest below this level.)

Agreed that we’re better confused than phished, of course. However, we ought to strive to make things actually work, no?

(Comments won't nest below this level.)

[...] Ka-Ping Yee: “OpenID, as currently used for single sign-on, facilitates phishing.“ [...]

(Comments won't nest below this level.)

Week’s Links…

Social Engineering: A Means To Violate A Computer SystemAn Introduction to Information System Risk ManagementInvestigations Involving the Internet and Computer Networks List of frequently seen TCP and UDP ports and what they meanReview: Six Rootkit Det…

(Comments won't nest below this level.)

[...] OpenID 2.0 and Phishing January 21st, 2007 | Category: OpenID, JanRain, Identity, Phishing There has been a bunch of discussion about OpenID 2.0 and how the latest draft does not address phishing at all. [...]

(Comments won't nest below this level.)

OpenID providers could do something I’ve seen bank websites do: When you sign up for an account, it asks you to pick an image from a small collection they provide, and then to give a title to that image. Whenever you go to the page to type in your password, the image and title you selected should appear above the login form. Users are told to never type their password on a page unless they see that image and title. This is much easier than asking users to bookmark things, and it’s very safe.

(Comments won't nest below this level.)

Providers could do that, if they wanted. But I don’t expect the personalized-image scheme to work, because it’s susceptible to a man-in-the-middle attack.

If I want to phish your password, I’ll go to the provider and attempt to log in as you. The provider will show me your image and title. Then I present that image and title to you when persuading you to give me your password.


Ping, I like the way you think. Admitedly, this is one of the password-less ideas I had but it’s neat to find others thinking along the same line. Oh, I liked your Passpet idea also. :-)

(Comments won't nest below this level.)
Andrew Cox wrote:

(Comments won't nest below this level.)

Looks like Simon went and implemented this as part of his idproxy service.

(Comments won't nest below this level.)

[...] In recent days, Simon Willinson and then Ka-Ping Yee proposed having Alice use a bookmark to reach her OpenID server, rather than rely on the web site to redirect appropriately. This is interesting, and one of the OpenID implementors, JanRain, thinks so too. [...]

(Comments won't nest below this level.)

Dear Ping,

I don’t quite follow your walk through:

Go to my OpenID provider & “log in” with OpenID URL & Password.
Visit a site I’ve never seen before.
Enter my OpenID name and click “Log in”.
See the challenge page for my OpenID provider.
Return back to the newly added site.

If you were prompted for a password - something did go astray.

Yours puzzled,


(Comments won't nest below this level.)

If you always go directly to your OpenID provider to enter your password, then there’s no problem. The problem is the case where the relying party redirects you to your OpenID provider’s login form.


[...] It’s not all rosy though. Many people have pointed out that the OpenID process is very susceptible to phishing attacks; but that’s a problem we’re going to have to solve somehow anyways, and I think the proposed solutions are pretty decent. Technorati Tags: authentication, openid, security, single sign on, usability [...]

(Comments won't nest below this level.)

Some interesting blog entries on OpenID with comments on phishing and other issues:


Should We Support OpenID?

(Comments won't nest below this level.)


OpenID This page has not been filled in yet. Notes from Sunil (email): And of course, UCAP can prevent it through it’s Defense is depth approach (Security Skin, EV SSL, Reputation Service, Stronger Username/password)…….

(Comments won't nest below this level.)

If I have to retry the transaction (comment posting or whatever) at the original site, then I’m simply not going to use it. Sorry.

Further, I might realize that I have to login only after I write my comment. There’s a chance that the data will be lost when I try to get back there. If this happens, the user will VERY QUICKLY learn not to use your service EVER AGAIN.

(Comments won't nest below this level.)
Daniel Chien wrote:

I have a simple way to detect phishing website by checking the IP address of the phishing website. On the Internet, everyone has an IP address. You can not fake your IP address due to IP two-way routing. Phishing website must use an IP address and can not be same as legitimate financial institution IP address. By comparing the IP address, we can know this is a phishing website or not.

(Comments won't nest below this level.)

[...] Post It #6 — Posted under de, en, Google, Humor, OpenID, Post-It, Software —BookmarkID? Ka-Ping Yee came up with a funny idea on how to battle phishing using browser bookmarks. [...]

(Comments won't nest below this level.)

I have a web server of my own, and I set it up to verify SSL client certificates when I’m browsing against a CA that I created, and I used a customized version of phpMyID to verify that I’m using a valid certificate and authorize me automatically.

My client certificate private key resides on a smart card, so it can not be copied even if my client computer is compromised.

Firefox supports smart cards out of the box using PKCS#11

Theoretically, this level of security can be provided by any OpenID provider. That solves the phishing problem.

(Comments won't nest below this level.)

Also, Verisign offers a ‘two factor’ OpenID authentication, so even if you phish in exactly this way, you would only get their password, but not compromise their fancy keyfob (Unless the algorithm on that thing is bad)

(Comments won't nest below this level.)

Theoretically, you can even use wacky authentication schemes. Like:

- You get to your login page, and up comes a little animation telling you the phone number to call to enter your PIN.. and when the phone system gets your pin, the page authorizes you, and if it gets a wrong pin or nothing within 60 seconds, it fails out. You could even call up and answer some security questions to some agent and have them click release or not.

- You get a list of passwords at the beginning of the month, and you can use each one only once.

- You can use your passwords three or four times in a row, until it asks you one of the security questions you came up with when you signed up, and if you mess it up your account is locked until the issue can be resolved.

- You get your OpenID through your ISP, and your ISP checks your IP against its radius accounting table, and determines if your IP is actually logged in with that username in order to get its internet access, and if so, it automatically grants access (A phishing proxy would automatically always fail)

That’s actually what really attracted me to OpenID. It gives you complete freedom to choose the level at which you feel comfortable with your own authentication onto sites, and who you trust to help you provide that. You could even set up an OpenID that just lets anybody in, if you so chose.

(Comments won't nest below this level.)

Sorry for all the posts, but I keep thinking up new ways to solve the problem :p

We could also instruct users (right in the login page) to check the HTTPS credentials and verify that it says the proper company name every time they log in.

Compared to my other four or five ideas, that one’s pretty weak, and relies entirely on a lack of user stupidity.

Another good idea:
High security sites like banks and such should not use OpenID :p For this reason, and because the bank site’s ISP can do a DNS man-in-the-middle attack on them, if their provider isn’t using ’smart mode’, or if their provider is rarely used.

(Comments won't nest below this level.)