I've tacked on another minute of video to the simple single sign-on screencast, in order to demonstrate Johannes la Poutré's Password Composer. I struggled a bit with how to present this to a general audience. Clearly Firefox is required, but Greasemonkey is optional: one version requires it, another runs as a standalone Firefox extension. In the end I decided to show the Greasemonkey version but omit the installation of Greasemonkey itself, just to keep things moving along.
This particular example makes an interesting counterpoint to last month's assertion, by Forrester's Nate Root, that "Greasemonkey will cause you nothing but headaches." I would argue that the various Firefox-based password-hashing extensions represent a potent cure for a whopping enterprise IT headache. I wouldn't, however, argue that Firefox won't also create some new headaches. Clearly it will.
There's no line in the sand we can draw here with respect to Greasemonkey, by the way. Firefox's extensibility is the real issue. To underscore the point, Adrian Holovaty has recently put together a brilliant Greasemonkey compiler -- a web page that accepts the text of a Greasemonkey script, and spits out an XPI (cross-platform installation) file.
What matters in the end isn't how the extension is packaged and delivered, but how it's built. Because Greasemonkey lowers the threshold for extension writers, we're seeing lots of user-interface experimentation and innovation. This matters critically because the user interface is arguably the gating factor for the adoption of security protocols.
I was reminded of this fact by Gordon Mohr, who pointed me to this Stanford project on password hashing. The project's write-up details a bunch of important challenges that any password-hashing solution must overcome. But while I can read the project's code -- which takes the form of dozens of C and C++ files -- I couldn't make effective use of it to evolve variations on the theme.
I could, however, evolve Nic Wolff's solution, and others are doing just that. The other day, I learned of two different Greasemonkey variations; they both interoperate with the original; I hope others will surface too. In light of all the carefully-engineered technologies that people have flat out rejected over the years -- e.g., S/MIME -- this genetic diversity seems like a healthy trend. We need to figure out what makes sense to people, and there may not be a single flavor that appeals to everybody.
This won't be a cakewalk. As Firefox and its extensions grew in popularity, it was inevitable that the bad guys would take note, and they have. Secunia lists 80 vulnerabilities for IE and only 16 for Firefox, but the recent trend tells a different story. In 2005 alone, it's IE 6 and Firefox 16. And while IE's worst unpatched flaw (from way back in 2003, oddly) rates a "Highly Critical", Firefox's worst unpatched flaw (found just two days ago) is "Extremely Critical".
As I've said before, the methodology used by the cathedral does not necessarily yield less secure outcomes than those produced by the bazaar. The reduction of IIS 6's attack surface area, for example, has been a dramatic turnaround that's been largely unnoticed -- though this report has recently made some waves. The fact is that software isn't secure because it's open source, it's secure because it's secure.
Much of Firefox's value flows from its extensibility, and that leads to both opportunities and challenges. If a vibrant ecology of extensions can breed usable solutions that enable people to practice better password hygiene, that's a huge win on the security front. It's also plainly a source of new risk. There are various and complementary strategies to mitigate that risk. My hunch is that a healthy competition between the cathedral and the bazaar can help us arrive at the right mix.
Former URL: http://weblog.infoworld.com/udell/2005/05/10.html#a1230