Phillip Hallam-Baker's Web Security Blog

My first law of usable security is that the user cannot be secure unless they have the information necessary to perform their tasks securely. How do we achieve this?

The first step is to do some use case analysis that is grounded in real world user tasks.

Many security use cases are of the form 'Alice wants to set confidentiality protections on her X directory to stop anyone but Bob reading them'. That is not a security use case, it is a description of how to meet the use case. This may appear obvious, but I have seen a room full of security experts develop 'security use cases' that are entirely of this form. Such use cases are useful when doing architectural design but they are worse than useless for usability analysis.

A real security use case for assessing usability would be something like 'Alice has a set of documents. The documents are confidential and must not be read by anyone other than Bob. Use case (1) how does Alice store the documents in the office, (2) work on the documents at home, (3) communicate the document drafts to Bob'.

In other words, a security use case is identical to an application use case, it is in fact an application use case. The only thing that changes is that the scenario calls out the fact that the documents are subject to confidentiality requirements.

Next: Task Analysis for WiFi.

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

Tim Mather has an interesting piece in Secure Computing on Identity 3.0. Although we are currently in the throes of Identity 2.0, it is not too early to think about 3.0.

Tim mentions my argument for attribute only authentication and unlinkable identifiers in The dotCrime Manifesto. Attribute only authentication is already here from a technical point of view, you can do it in Shiboleth which is built on SAML. But unlinkable identifiers has been a problematic area because there has been a great deal of IP floating round and navigating the channels has appeared to be a difficult proposition.

One factor that may have simplified the issues there is the acquisition of Credentia by Microsoft a few months back.

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

As readers of this blog will know, over the past few months I have been considering the issue of economics of protocol deployment and the issue of security usability. (see Part 1 Part 2.

If we are going to improve the state of security usability we need to get into the product design loop so that usabile security is an upfront design consideration, not an afterthought. To do that we need to establish clear failure criteria that unambiguously identify a design that cannot possibly be considered usable under any circumstances. Earning a pass on such criteria must be considered a necessary but not a sufficient condition to achieve usability.

One such failure criteria is sufficient information. In many cases the user simply does not have enough information to determine how to do their task safely. For example:

• When a user receives an email that purports to be from her bank there is no reliable means for them to know if the message is genuine or a forgery.
• When accessing a WiFi access point at a coffee shop, the user has no way to tell if their computer has connected to the genuine access point or an 'evil twin'.
• My watercooled desktop computer recently developed an overheating fault. Diagnosis of the problem took days longer than necessary because the machine does not keep a log of the reason for the emergency shutdown.

Note that failing to give the user the necessary information at all is a distinct problem from giving the information in a form that the user can use. The traditional SSL padlock icon display does make it possible for a cryptographic expert to determine the security state of a connection. This is an even more fundamental problem: the user does not get the information at all.

Some of these cases are due to poor application design but the WiFi case is due to poor design of the standard. There is simply no way that a company can deliver an acceptable security user experience using the tools provided in the WiFi standard.

Next: how to determine whether the user has sufficient information or not.

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

Net-Security has found the list of book signings for RSA. People who want to buy a signed copy from the bookstore can find me there at 12 noon just after the cryptographer's panel. People who already have a copy who want it signed can find me after one of my sessions and/or at the VeriSign booth.

Phillip Hallam-Baker, Principal Scientist, VeriSign Inc. has authored The dotCrime Manifesto: How to Stop Internet Crime. He will be at RSA Conference and speaking on two panels: DEV-107 Security Usability: The New Challenge and STA-302 Extended Validation: Raising the Bar for Internet Trust.

Ira Winkler's newest book was published shortly after RSA Conference 2007, Zen and the Art of Information Security. Ira is presenting EXP-108 How to Take Down the Power Grid and is participating on the panel CONS-107 Protecting the Homeland: How to Win the Botnet Battle?

Billy Hoffman, HP Security Labs and Bryan Sullivan, Microsoft Corporation, recently published Ajax Security. They will be presenting HT2-303 Ajax Applications: A Blueprint for Disaster.

Andrew (Yehuda) Lindell, Chief Cryptographer (and Assistant Professor), Aladdin Knowledge Systems (and Bar-Ilan University, Israel) has published a new book, Introduction to Modern Cryptography. He is on three Cryptography panels: CRYP-106 Cryptographic Building Blocks, CRYP-107 Fairness in Secure Computation and CRYP-108 Message Authentication Codes.

Brian Chess & Jacob West, Fortify Software, have written Secure Programming with Static Analysis and are presenting EXP-401 Learn to Stop Fuzzing and Find More Bugs.

Posted by Phillip Hallam-Baker at 06:51 AM | Permalink | Comments (0) | TrackBacks (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 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.

The answer of course is that while I love the MacBook Air hardware and the fact that thanks to Bonjour it automatically configured itself to use my network printers without the need to load any drivers and the fact that it took less time to get it to work with my Home Server than it did the Windows Vista boxes, the fact is that there is absolutely no real difference in the security experience.

Admittedly my test is not within the scope of use cases generally considered for consumer products, but that is part of the problem. For some reason it is believed that security is an exclusively 'enterprise' consideration. The idea that a doctor or a lawyer (or an engineer who specializes in Internet crime for that matter) might have information they want to keep confidential is clearly not being considered as a use case.

Clearly it is going to be difficult to get the O/S vendors to pay attention to such use cases. So how about this one, what if a parent has collected a large quantity of pornographic material that they do not wish to be available to their minor children?

OK having got their attention to the use case, how do we demonstrate that the current usability experience is not safe at any speed? Thats the subject of my next post.

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

What does it take to make the Internet secure? This video from 'the attack of the show' shows what it takes.

In case you are wondering why the guy is so concerned for the wellbeing of shopping carts, its because studies have found that deploying Extended Validation certificates on a Web store front has reduced the rate of cart abandomnent. In the case of Scribendi by an astonishing 27%

Is this because an EV certificate gives users greater confidence or are people more willing to buy when they see that a merchant shows they care about securing the Internet? Whether either or both is true, the customers certainly appear to be noticing the green bar experience.

Posted by Phillip Hallam-Baker at 07:51 AM | Permalink | Comments (1) | TrackBacks (0)