WordPress InfoCard integration code

Update:  There are now excellent community-based and commercial implementations of Information Card code for WordPress, php, ruby, “C” and other languages.  I've left this zip here for documentary and pedagogical purposes only.

 I've been wanting to share my experiences adding Information Card support to identityblog for quite a while now.  I just haven't had the time.

I started by publishing my work on building the necessary code for handling secure identity tokens.  But then I got interrupted with the necessities of life – like shipping Cardspace.

Anyway, now I'm ready to present my integration code.  Very little of it is unique to WordPress – it is really code that would in general apply just as much to any other piece of software.  Someone could easily factor my code so the interface is a little cleaner than is currently the case. 

When I had to actually alter wordpress files (only 3 of them), I just show the changes that are necessary.  You'll have to download the original files from wordpress to see what I'm talking about (version 2.0.4) in context (usually not necessary unless you are making the changes in your own version.)

Download my contribution here.  My assumption is that the root of this download is the same as the root of the wordpress directory. 


The files all begin with “infocard” so they're easy to delete if you want to.

I'll be publishing a number of pieces explaining why I took the approaches it did.  I hope this will get some good, concrete conversation going.  The first in this series is uncharacteristically wordpress specific – don't get discouraged if you're looking for something more general.  It talks about how I approached changing the wp-login page.  I'm pretty sure that even people thinking about infocard-enabling other products will find some ideas here that help them out.

Like my previous work, you can use this code in whatever way you want.  My goal is to help as many people as possible understand, use and deploy information cards.

UPDATE:  Thanks to Samuel Rinnetmäki for pointing out the need to warn readers not to install “as is” in an operational directory – it had never occured to me they might do this…  I've edited the  ZIP to make this impossible (09-02-2008).

WordPress vulnerability at identityblog

Sun's Rohan Pinto has spent a fair amount of time this week using a recipe that has been discussed in the Blogosphere recently to hack into my blog, which runs WordPress 2.0.1, and then apologizing for it (I appreciate that, Rohan).

He was able to use a vulnerability in WordPress to employ his “subscriber” account (which normally only grants comment rights) in order to import a fake post onto my site (I've since removed it but it is shown at the right).

The exploit used was described about three weeks ago (July 27th, 2006) when Dr. Dave published his “Critical Announcement affecting ALL WordPress Users.”  All in all, it was a fairly stern warning.  I would have upgraded to a newer version of WordPress but couldn't because I was travelling:

If you are running WordPress as your blogging platform and if you have been trusting enough to leave User registration enabled for guests, DISABLE IT IMMEDIATELY (in wp-admin >> options: make sure “Anyone can register” is not checked).

Additionally, delete or disable ANY guest account already created by people you are not sure about.

Leaving it open and letting people sign-up for guest accounts on your WordPress blog could lead to incredibly nasty stuff happening if anybody so desired. And trust me I am not exaggerating this. So don’t wait a second to disable this option and please relay the message. WordPress dev team has been notified a while back and I dare hope they will soon start acting on it, if only by relaying a similar announcement through the official channel (as well as, of course, releasing a proper patch).

Sorry for the shrill hysterical tone, but this is a big deal. However, disable that one option and you are fine, no need to panic further :)

[cheers go to Geoff Eby for discovering and bringing this insane security exploit to my attention]

Initially Rohan entitled the post that described the exploit, “Is Cardspace Secure Enough?”.  That bothered me, since the exploit had nothing to do with InfoCard or Cardspace or my PHP demo code.  Rohan was good enough to later make that perfectly clear:

Pursuant to my prior post. Please do take note of this. I would like to make it crystal clear to everybody that me logging into Kim’s blog and publishing as “him” was NOT a infocard exploit, but rather a “wordpress” exploit…

Please, please, please do note, that this IS NOT a infocard hack.

Conor Cahill read about the exploit and commented

Access Control is always going to be a responsibility of the entity managing the resource (in this case, Kim's blog is managed by a wordpress installation that he setup on his server, so his server must manage the access control).

The selection of the tool to manage the rescource will be based upon the reliability of the manager and the value of the resource.

I'm sure Kim wouldn't have put his bank account up on wordpress without a lot more testing and perhaps requiring someone else to stand behind it should there be such a problem…

All of this is true, of course, with the exception that my blog usually has more in it than my bank account.  Further, in the case of WordPress, it is the application that manages the security, not the underlying operating system or environment (in this case a LAMP stack) or hardware.

Of course, I didn't choose WordPress because it was the most secure solution in the world;  I chose it because it was an interesting blogging tool, with a lot of cool features, and would help me learn about the issues confronting people on non-Microsoft platforms so I could have a more inclusive view of identity problems.  And it has been great for those purposes.

You might think I would be abandoning WordPress.  But I won't.  I like it and want to continue to explore what it is like to work with it, and help make it better.  To me the real lesson in all of this is that the approach to remote operations used in WordPress – and almost all web-based applications – is just not adequate.  The more you know about all the exploits that are possible in the http world, the more you want to run headlong into the world of Web Services, where each transaction has its own security environment, in the sense that the security environment travels with each message and operation.  In the same way, SOA moves the control of authorization from the application to the operation definition process, so creative application authors like those who built wordpress, don't have to take sole responsibility for all the subtle security problems that will inevitably arise as we move further into the virtual world.

I take it for granted that given all my pontification about identity and security my site will be used in creative ways.  So I have no ill feeling toward Rohan.  The important thing is the conversation and the learning that come out of this.

So to rephrase Conor, in this case, the selection of the tool to manage the rescource will be based upon an analysis of the risks and benefits of using an emerging technology to reach others working on the issues.