Phillip Hallam-Baker's Web Security Blog

Step one in every 12 step program is knowing that you have a problem. If we are going to do anything about terrible security usability we need clearly defined criteria that allow us to identify terrible security usability experiences that require repair.

This approach is entirely different from that of usability specialists such as Ka Ping Yee who has been working on a set of principles for good security usability. Good design of any type is an art. Bad design is simply the result of making mistakes.

That is why I think that we need to start thinking about of laws of security usability. By laws I mean a set of rules that are sufficiently accepted and well specified that we might at some point in the distant future after consensus has been established in the field and vendors have had a chance to deploy new products in response, consider breaking one to be a potential liability issue.

The zeroth law of security usability would be that if it isn't safe, it isn't usable. Nobody would claim that a light switch design, however pretty or intuitive was 'usable' if incorrect use was liable to result in electrocution. We should apply the same approach to computer systems.

Rather too often the response to making security a higher priority in the design of software applications is that to do so might make them less user-friendly. The result is that all to often we have designs that it is simply not possible for the user to use securely.

One example of this problem that is becoming justly notorious is email. There is absolutely no way in which the email user can expect to know that the email they receive is in fact from the purported sender or not. The problem of phishing is a direct and predictable result. Many proposals have been made to fix the problem but these have all suffered from the pushback that users might not be able to use them effectively.

The reverse also holds: a system isn't usable it probably isn't going to be safe. The modern engineering practice of ergonomics originated in the design of airplanes after pilot error was identified as the cause of many crashes.

Posted by Phillip Hallam-Baker at 09:42 AM | Permalink | Comments (0) | TrackBacks (0)

For the past few months I have been paying close attention to the reasons why people don't use security technology when it is available. A common theory in the cryptography community is that people are just too lazy. We have plenty of security systems that could be used to stem the flood of data breaches tracked by the folks at emergent chaos and elsewhere. But most companies don't bother to. Every major email client has come with built in encryption and signature capabilities for over a decade but very few people turn them on and of those even fewer actually use them every day.

Security usability has become a hot topic in the field. But to date it has been dominated by usability specialists who are looking at ways to produce the most effective, most secure security experience. It appears to me that we are repeating the mistake we made in the mid 1990s when we assumed that what the user wanted was 'security' when what the user really wants to do is to achieve their objective without the need to worry about a nasty surprise.

I would very much like it if browser providers provided an 'Extended Validation' security experience with even greater visual impact than IE7's green bar. It would certainly be good for VeriSign business. But browser providers have a marked tendency to be stingy with the pixels they will allow for the security experience because they know that when they do provide an arresting user experience the user is quite likely to demand a way to turn it off. People are noticing the green bar and reacting to it or there would not be a measurable reduction in the number of abandoned shopping carts.

Another subtle difference between usability engineering in general and security usability in particular is that security usability cannot be successful as a product differentiator which is precisely what most usability engineering processes are designed to achieve.

Giving a user a system that they can use securely is not the same thing as giving them a system that they will use securely. And in any case the discussion of what the perfect security experience would be is besides the point as a large number of security interfaces are simply unusable.

A case in point here is the Access Control List (ACL) system that has become ubiquitous in modern operating systems. ACLs are effectively an orange book and common criteria requirement and all modern O/S are designed to be compliant. I first used ACLs on VMS 3.0 more than twenty years ago. All I wanted to do was to set up my home Windows system so that only I could see a particular set of files.

Should be easy? Think again, it took me several hours to achieve the desired effect and I know rather more about the likely cause of the problems than the average user. My home configuration is pretty much the state of the art for Windows in the home with Vista Ultimate and Home Server. I only succeeded after realizing that Home users were expected to do all their security configuration through the Windows Home Server Console. The fact that right clicking on a directory brought up a 'security' tab was just there to confuse.

The predictable response to my complaints was 'go get a Mac'. So of course I did. So what happened? Well thats after the jump.

Continue reading "Unsafe at any speed?" »

Posted by Phillip Hallam-Baker at 08:46 AM | Permalink | Comments (0) | TrackBacks (0)

As folk who heard me speak at Financial Crypto this year know, I am currently trying to develop laws of security usability. We have a significant quantity of raw information concerning usability of particular systems but few attempts to systematize and generalize from these data points to develop actionable design rules for designing usable systems.

As more details of the Societe Generale incident emerge, it begins to look like a usability problem. Dominic O'Connor at the Register presents an all to credible explanation of how the disaster might well have occurred: Controls were in place that should have detected the issue and may well have done so, but it appears that the usability of those systems was flawed. The managers followed the path of least resistance.

Posted by Phillip Hallam-Baker at 09:32 AM | Permalink | Comments (0) | TrackBacks (0)

Over the weekend I spent some time trying to fix my son's computer as the networking had stopped working. It is quite possible that the explanation could be that the card has stopped working, that the software is misconfigured or that the antenna is broken.

The point is that it should not be my job as a user to work out the reason for the problem. The computer should work it out and tell me.

Engineers have an infuriating level of tollerance for systems that need manual tweeks. In the original WIFi security scheme WEP the user is expected to type in a long secret key in hexadecimal to enable security. Windows XP makes this twice as hard as necessary by making the user type the key in twice. My son's computer stopped working after a 'repair' man temporarily turned of WEP while working on a modem problem (don't ask why).

When I upgraded my network I decided I had had enough of WEP so I bought a new router that supports WPA-PSK.

The new router works just like it should. It still needs a bit more set up than I think it should and the designers have not thought about how to transition a network from WEP to WPA. You can choose one or the other but not both. Both is what you need when you have five machines working on WEP two of which won't work on WPA at all.

We still build computers the same way that cars used to be built. The worst expect to be maintained by a full time mechanic, the best aspire to allow the user to be their own mechanic. Modern cars come with four year bumper warranties and are designed to run 10,000 miles between services. We still have not got to the point where we expect computer systems to just work without complaints or excuses.

Why did we have to wait six years to get a security mechanism for WiFi that was usable and secure?

Posted by Phillip Hallam-Baker at 06:01 PM | Permalink | Comments (0) | TrackBacks (0)