I remember being incredibly incensed by a Catalyst conference panel some years ago, where one of the panelists haughtily declared something to the effect of “if engineers built bridges the way coders wrote programs”… you can guess the rest of the analogy. The expectation seemed to be that if we somehow only allowed “licensed” programmers to work and kept the rest out, life would be ever so peachy.

I’m afraid this sentiment hasn’t grown on me with time. It is absurd to imagine turning every programmer out there into a security expert – and just because they aren’t a security expert, it doesn’t mean they shouldn’t be programming. As user-centric identity technologies ‘tip’ into mass adoption, people of all experience levels will be coding with the goal of accepting information cards, some of whom will be at or beyond the limit of their understanding as they follow someone else’s instructions, or incorporate someone else’s sample code. The challenge is to make it easy for all of those people to do it right.

This is my hope for 2007. It is inspired by an article, written by Jeremiah Grossman and published at gnucitizen.org. Here is a quick excerpt:

The only way I see software security improving significantly is if “security” is baked into the modern development frameworks and be virtually transparent. Remember, the primary developers mission is to pump out code to drive business and that’s what they’ll do not matter what. When developers find that its WAY easier and WAY better to do RIGHT by security, then we’ll get somewhere. Not before… being a web application vulnerability assessment vendor positions you to see this happen first hand. Our data makes it quite clear, which websites are more secure than others.

At WhiteHat we assess vulnerabilities in hundreds of websites each month coded in all sorts of programming languages. Its clear to us systems designed with modern development environments like .NET and J2EE are WAY more secure than their predecessor. Session handling issues go away. So does large amount of XSS and SQL Injection. Are they all rock solid and infallible? No, of course not, but the differences are hard to ignore. To improve the security of software, the development framework seems to be making the most difference.

I consider this an excellent description of what the Windows Communication Framework gives us. Of what Higgins will give us. Of what Rob Richards’ xmlsec PHP libraries give us. A layer of abstraction written by those who know how to be secure, so that not everyone has to be an expert.

So – my compliments and best wishes for 2007, to the people who are working hard to bake security into user-centric identity components, instead of bolting it on later. You know who you are. Thank you for thinking of it, so that I don’t have to.

Lastly, I’d like to offer up an alternate analogy. I think what Jeremiah Grossman is talking about, and the ways in which all of the identity frameworks are already building their systems could be compared to how pyro-technicians create fireworks.

All sorts of hard work, scientific knowledge, research, and testing combines to make a dangerous combination of materials into something that can be safely used simply by planting it, pointing it the right direction and lighting a fuse, because you can be pretty damn sure that some of the people who are going to be playing with the finished product are not going to have pyrotechnical training. In fact they will probably take what you’ve done and manage to turn it into something that you never thought anyone would do –

— but if the pyro-technicians have done their jobs well enough, the world will still be able to enjoy the end result and reason for having started this all in the first place, in reasonable safety. Note that nobody can make a firework 100% safe — because nobody can guarantee that it will be used properly. What they can do is to make sure that when it is used correctly, it is very safe indeed.

My goal for 2007 is to help with the using correctly part. More on this soon…