<? DriftLogic ¿>

Recently, I participated in a meeting with management and developers from another organization which, in many ways, is a direct competitor for part of our web offering. We reached the point where the discussion came down to the nuts and bolts of how things are done and at one point, the lead developer made the claim that their system had never had a break in.

The thought of making a claim like this has crossed my mind once or twice. As far as I can see, none of my servers or my code has been broken into. I've never had to deal with recovering from a malicious attack, or hear from angry users who have had their credit information exposed to the public.

As far as I know...

Security is about as close to a pure art form as development gets. There is no absolute right and wrong in dealing with it, particularly because so much of it is human dependent. I'd say that security is more dependent on the human factor than interface design. So much of proper security is based upon both educating and informing users, but more than that, making them give a damn.

Requiring login information for sites has become so prevalent in development these days, that it has almost become noise as users move between sites. A Prinston study found that users tend to reuse passwords between sites in order to make them more memorable, on average recycling 3 different passwords between created accounts 1. Login information for websites became a chore for users some time ago, leading to integrated password management for browsers. Efforts such as OpenID have attempted to create a single sign on type mechanism for the web, with limited success. The biggest adopter of OpenID right now being Yahoo.

Developers in their security requirements first started by making suggestions to users about the process, informing them about password strength and reuse of account information. That approach has changed on the web in the last year or so, with sites like Google enforcing a minimum password strength for user accounts.

Internally to applications, developers are taught to store user data in encrypted forms, so that in case of break in, there is some last line of protection. Some have learned the perils of storing plain text passwords better than others.

So while a developer can feel confident that they've followed best practices in regards to secure design and as such, their application is 'secure'. Users truly hold the power in regards to security. As such, the attitude in development is that security focuses on protecting the enterprise, rather than the individual user. This attitude is understandable, considering the direct influence a developer has over user habit ends at the login prompt, but is also regrettable. Regardless of what information you store or how you profit from it, it doesn't have value without a user willing to trade for it. So while users may feel that security is a hinders the actual access of information, they would equally shy away from services which lack even basic protection of their information.

While approaches like OpenID may succeed in the long term, users who only register at one or two sites won't tend to want the extra step of registration at a third party. It would take a major provider like Yahoo transitioning over to OpenID exclusively to encourage widespread adoption.

Update:

Here's a good article outlining the absolute basics for secure logins on websites: http://www.topmost.se/personal/articles/casual-cryptography-for-web-developers.htm