Cryptosmith

Will Norris is working on a revision to OpenID for WordPress. This is good, and I have some observations and suggestions. At the moment the OpenID plugin works pretty well - I have separate logins delegated through domains I own. I routinely log in through OpenID for both routine and administrative activities.

I’ll briefly note the things I like, some problems, and then make observations on proposed changes.

Good Things

• The critical things work well through the graphical interface. Unlike SSL on WordPress, you don’t have to muck with configuration files to turn things on and off.
• It’s mostly load-and-run.
• As an OpenID user I can myself add OpenID URLs to my account. So I can add variations of an OpenID URL. Also, this feature provides a diagnostic: you can try different URLs and see which ones work.

Problems

• Support of SSL - a site doesn’t “look” secure unless it supports SSL, and there are obvious weaknesses in OpenID if you’re delegating from a non-SSL site. In my experience, the plugin doesn’t seem to work well with the built-in WordPress 2.6 SSL support. These things work fine with regular logins, but fail with OpenID logins:
  • When I turn on FORCE_SSL_LOGIN, I can log in using https but I have to manually enter a non-SSL URL to get to the admin pages. Some error seems to redirect the admin links to the login page.
  • When I turn on FORCE_SSL_ADMIN, I get logged in but I can’t use the Admin pages. Everything redirects to the login page. If I go back to the blog pages, I’m shown as logged in.
• Better diagnostics - OpenID can fail at several different points, and the failure may be due to the plugin installation, the ID provider, the text provided by the user, or problems with the PHP libraries. There’s no way to tell which thing has failed. While it might not be practical to incorporate better error diagnostics in the regular, running code, it might be possible to construct some tools to run experiments to isolate problems.
• Intermittent failures - one of my blogs rejected all OpenID logins for a while and then, for no apparent reason, started accepting them again. Perhaps the failure was the plugin, perhaps it was something else, but again it’s hard to track such things down without better diagnostics.

The Proposed Improvements

• Stability improvements - hooray!
• Multiuser delegation - a great idea! Right now I’m doing it by hand. This would allow family members to use our family blog ID as their OpenID identifer. Here are some suggestions
  • Make identifier overhead as small as possible. For example, a blog posting suggested that the path “/author/” be inserted between the blog’s URL and the user’s ID. Perhaps the string should be user-selected. Obviously it mustn’t conflict with page and category names. I’d want to minimize typing by using a single letter, like “/u/”.
  • Be sure it works with SSL. As noted above, there is an obvious cut-and-paste attack on OpenID delegation - just direct it to a subverted identity server that always says “Yes”. SSL makes this impractical.

Improvements I’m less inclined to use:

• Owner delegation - who wants to be stuck with only one user ID? I suppose a lot of people will use it, and that’s how I first tried doing delegation.
• Blog as OpenID provider - This seems like a bad idea. Authentication isn’t what WordPress is about. I can see why a hobbyist might use this as a toy, but I wouldn’t want to trust anything serious with such authentication. On the other hand, I suspect it’s easy to provide since all the pieces are more or less in place, and some people will be inclined to play with it. Of course, this has to work with SSL unless it’s clearly marked as being a toy or a “low assurance service.”

Posted under Information Security & WordPress |