Phillip Hallam-Baker's Web Security Blog

Over at Emergent Chaos Chris Walsh has been busy savaging Paul Murphy's predictions for 2007. In particular Murphy's prediction that a class action will be brought asserting that using an operating system which competes with his pet favorite operating system represents an 'industry dumbest practice'.

Chris correctly points out that of the top 20 data breaches recorded at attrition.org the use of the operating system in question can be rulled out in 17 cases and in the other 3 cases we don't have enough information to judge. He is certainly correct in pointing out that running the most secure O/S on the planet won't help if your problem is that a thief stole your unencrypted backup tapes, or a laptop, or bribed your people, or did any of the things that are most likely to lead to a security incident.

The point that he does not make but should so I will make it for him is that if you are using security for this type of cheap point scoring you obviously don't take it as seriously as you should.

Posted by Phillip Hallam-Baker at 8:31 PM | Permalink | Comments (0)

The BBC Reports that the Virginia police have banned the use of radio codes such as 10-4.

The problem is that while some codes such as are standard across the forces others are not. So 10-50 can mean a car crash or officer in trouble. The incompatibility lead to serious communication problems when multiple police forces responded to the attack on the Pentagon on 9/11

Like the QWERTY typewriter keyboard the 10-4 codes were introduced so that humans could adapt to the limitations of technology. Early police radios were bulky with poor sound quality. Using codes made it easier to communicate information quickly and unambiguously. Once established the codes survived.

The lesson here is that technical interoperability can be defeated by social incompatibility. If the codes had been standardized when they first emerged they would still be useful today.

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

The hottest topic in computer security these days is usability. People are finally beginning to understand that it does not matter how good a security scheme is if people refuse to use it. Telephone companies have known this for years which is why it is perhaps a good idea to take a look at how user-unfriendly the telephone system has become of late.

When a call comes in on my home number the caller ID shows the number that called XXX-XXX-XXXX. But if I try to call the number back an automatic voice tells me 'you must first dial a one'. How's this for an idea, instead of telling me to dial a one why not just connect me to the right number since you know what it is?

In my area every number has to be dialed using ten digit dialing and as I have VOIP service the same carrier handles the call regardless of how it is dialled. So why exactly do I have to dial a 1 in front of the number?

The problem becomes even worse when trying to cope with international dialing. In the UK the international dialing prefix is 00. In the US it is 011. But when you call the UK from the US you must remember not to dial the first zero of the area code or you will get a stupid voice telling you to redial without dialing the zero. Got that?

There are no doubt good engineering reasons for this behavior but that does not excuse the treatment of the customer. A computer system should know its place, it must act as an obedient servant, not a jobsworth bureaucrat.

And that sounds like a pretty good principle to apply to computer security systems as well. There are simply too many dialog boxes that are thrown in front of the user because that was easier for the engineer to do than to solve the problem they report.

Posted by Phillip Hallam-Baker at 5:13 PM | Permalink | Comments (1)

Recently I attended two working group meetings at Columbia discussing different aspects of security usability. At both meetings someone made the statement 'user's don't understand what parts of the browser are content and what parts chrome'. That is people who use browsers do not understand which parts of a browser window contain trustworthy information and those which do not.

This should not be a surprise: until this year security concerns were always trumpted by the notion that the content provider should have as much control over the layout of the page as is possible. The fact that there is a problem was only after phishing gangs started to use frameless javascript popup windows to overwrite the address bar and the padlock icon.

IE7 and Firefox 2 both make important progress in preventing the worst type of abuses. IE7 does not allow content to overwrite certain parts of the display deemed to be critical and every popup window has at least a minimal quantity of chrome.

But the legacy of ten years of ill-discipline persist. We still lack a clearly enforced boundary between content supplied by the Web site being visited and trusted metadata supplied by the browser. A clearly defined boundary exists, the problem is that it is not enforced. Little wonder then that users have difficulty determining what they can trust and what they cannot.

The problem is that even in IE7 the content provider can still inject untrustworthy data into several areas of the screen that a user might reasonably assume to be 'secure'. The title of the Web page is writen out to the window frame, the URI of the web site is written out to the address bar and if specified the favorites icon specified by the content provider is written out to the favorites list (the intended use) and the address bar.

Like cookies and Javascript, favicons were the result of unilateral deployment rather than a considered process and like cookies and Javascript the security impact was both profound and entirely ignored by the perpetrators. Displaying the brand of a bank in the chrome area of a Web browser has a profound impact on the user who has been led by ten years experience to expect information in the chrome area of the browser to be trustworthy.

Fortunately there is a positive side to this fiasco. We have identified a powerful means of communicating to the user. The problem is that the data provided is untrustworthy, a problem that we already have the means in hand to fix: SSL plus Extended Validation Certificates with embedded Logotype Extensions, the scheme I call Secure Internet Letterhead.

Posted by Phillip Hallam-Baker at 9:21 AM | Permalink | Comments (0)