Phillip Hallam-Baker's Web Security Blog

Perhaps the biggest challenge in Information Security today is usability. However good the cryptography is, it does no good unless the user is prepared to actually use it.

Everyone agrees that usability is good, but very few people agree on what usability is. And no, the answer is not 'get a Mac'. I do have a MacBook Air, I like the hardware, but I don't see a tremendous difference in usability between the OS/X and Vista. And neither system allows me to send secure email with the same ease of use as insecure email.

Usability testing is a great way to determine user acceptance. Usability testing delivers an impressive return on investment for vendors because the lab testing conditions almost precisely match the conditions in the salesroom and to a lesser extent the type of testing a reviewer performs. But laboratory tests are not very effective in determining how users will behave six months later after using a system every single day.

Folk tell me that if you take 60 confused users, split them into three groups of 20 and show them different security interfaces they are all still confused. Well what did they expect?

And so for the past few months I have been thinking about ways to avoid the need to perform testing by raising the bar for security designers. We don't need to rely on security usability testing if we can add security to a system without impacting the user experience at all.

SSL is the most successful security protocol today, precisely because it is so easy to use. Visiting a secure site takes no more user effort than visiting an insecure site.

At first i was thinking of calling this approach 'zero impact'. But that does not capture the full set of requirements as there are situations in which we want a security system to cause a modification of the user's behavior. 'zero impact' implies that the user will never notice anything. This is one of the chief drawbacks of SSL today: the user may not notice anything at all. Hence the move to Extended Validation certificates and the 'green bar' experience.

So instead I am thinking that 'Zero Overhead' is a better description of what I think we need to achieve:

• Configuration of the security system should be entirely automatic.
• A security control is 'zero overhead' with respect to a particular task if and only if the number and complexity of user interactions required to perform the task under the security control are less than or the same as previously without the security control
• The user should be provided with all necessary and available required information to make a decision with security consequences.

In other words, security should work in the application 'out of the box'. It should not be necessary for the user to register for a client certificate, much less renew it every year. Nor should the user be tasked with configuring Webs of trust or choosing their roots of trust. If a protocol requires these features they MUST be performed transparently without user intervention.

I believe that the last criteria is also essential, but have not quite decided if it is a separate criteria or a subordinate one. Too often the user is not given the information they need to do a job securely and 'usability' is given as the excuse. Should this be a part of the 'zero overhead' criteria or is 'inform the user' a separate criteria?

Posted by Phillip Hallam-Baker at 6:16 AM | Permalink | Comments (0)

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 9:42 AM | Permalink | Comments (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 8:46 AM | Permalink | Comments (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 9:32 AM | Permalink | Comments (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 6:01 PM | Permalink | Comments (0)