Light Blue Touchpaper

Last week, in retaliation against the heavy-handed response to planned protests against the BART metro system in California, the hacktivist group Anonymous hacked into several BART servers. They leaked part of a database of users from myBART, a website which provides frequent BART riders with email updates about activities near BART stations. An interesting aspect of the leak is that 1,346 of the 2,002 accounts seem to have randomly-generated passwords-a rare opportunity to study this approach to password security. (more…)

The usability community has long complained about the problems of passwords (remember the Adams and Sasse classic). These days, even our beloved XKCD has something to say about the difficulties of coming up with a password that is easy to memorize and hard to brute-force. The sensible strategy suggested in the comic, of using a passphrase made of several common words, is also the main principle behind Jakobsson and Akavipat’s fastwords. It’s a great suggestion. However, in the long term, no solution that requires users to remember secrets is going to scale to hundreds of different accounts, if all those remembered secrets have to be different (and changed every couple of months).

This is why, as I previously blogged, I am exploring the space of solutions that do not require the memorization of any secrets—whether passwords, passphrases, PINs, faces, graphical squiggles or anything else. My SPW paper, Pico: No more passwords, was finalized in June (including improvements suggested in the comments to the previous blog post) and I am about to give an invited talk on Pico at Usenix Security 2011 in San Francisco.

Usenix talks are recorded and the video is posted next to the abstracts: if you are so inclined, you will be able to watch my presentation shortly after I give it.

To encourage adoption, I chose not to patent any aspect of Pico. If you wish to collaborate, or fund this effort, talk to me. If you wish to build or sell it on your own, be my guest. No royalties due—just cite the paper.

Britain’s phone hacking scandal touches many issues of interest to security engineers. Murdoch’s gumshoes listened to celebs’ voicemail messages using default PINs. They used false-pretext phone calls – blagging – to get banking and medical records.

We’ve known for years that private eyes blag vast amounts of information (2001 book, from page 167; 2006 ICO Report). Centralisation and the ‘Cloud’ are making things worse. Twenty years ago, your bank records were available only in your branch; now any teller at any branch can look them up. The dozen people who work at your doctor’s surgery used to be able to keep a secret, but the 840,000 staff with a logon to our national health databases?

Attempts to fix the problem using the criminal justice system have failed. When blagging was made illegal in 1995, the street price of medical records actually fell from £200 to £150! Parliament increased the penalty from fines to jail in 2006 but media pressure scared ministers off implementing this law.

Our Database State report argued that the wholesale centralisation of medical and other records was unsafe and illegal; and the NHS Population Demographics Service database appears to be the main one used to find celebs’ ex-directory numbers. Celebs can opt out, but most of them are unaware of PDS abuse, so they don’t. Second, you can become a celeb instantly if you are a victim of crime, war or terror. Third, even if you do opt out, the gumshoes can just bribe policemen, who have access to just about everything.

In future, security engineers must pay much more attention to compartmentation (even the Pentagon is now starting to get it), and we must be much more wary about the risk that law-enforcement access to information will be abused.

I’m liveblogging the Workshop on Security and Human Behaviour which is being held at CMU. For background, see the liveblogs for SHB 2010, SHB2009 and SHB2008. The papers are here and the session reports will appear as followups to this post.

Back in January I visited TalkTalk along with Jim Killock of the Open Rights Group (ORG) to have their new Internet blocking system explained to us. The system was announced yesterday, and I’m now publishing my technical description of how it works (note that it was called “BrightFeed” when we saw it, but is now named “HomeSafe”).

Buried in all the detail of how the system works are two key points — the first is the notion that it is possible for a centralised checking system (especially one that tells a remote site its identity) to determine whether sites are malicious are not. This is problematic and I doubt that malware distributors will see this as much of a challenge — although on the other hand, perhaps by setting your browser’s User Agent string to pretend to be the checking system you might become rather safer!

The second is that although the system is described as “opt in”, that only applies to whether or not websites you visit might be blocked. What is not “opt in” is whether or not TalkTalk learns the details of the URLs that all of their customers visit, whether they have opted in or not. All of these sites will be visited by TalkTalk’s automated system — which may take some explaining if the remote system told you a URL in confidence and is checking their logs to see who visits.

On their site, ORG have expressed an opinion as to whether the system can be operated lawfully, along with TalkTalk’s own legal analysis. TalkTalk argue that the system’s purpose is to protect their network, which gives them a statutory exemption from wire-tapping legislation; whereas all the public relations material seems to think it’s been developed to protect the users….

… in the end though, the system will be judged by its effectiveness, and in a world where less than 20% of new threats are detected — that may not be all that high.

About a moth ago I’ve presented at the Security Protocols Workshop a new idea to detect relay attacks, co-developed with Frank Stajano.

The idea relies on having a trusted box (which we call the T-Box as in the image below) between the physical interfaces of two communicating parties. The T-Box accepts 2 inputs (one from each party) and provides one output (seen by both parties). It ensures that none of the parties can determine the complete input of the other party.

Therefore by connecting 2 instances of a T-Box together (as in the case of a relay attack) the message from one end to the other (Alice and Bob in the image above) gets distorted twice as much as it would in the case of a direct connection. That’s the basic idea.

One important question is how does the T-Box operate on the inputs such that we can detect a relay attack? In the paper we describe two example implementations based on a bi-directional channel (which is used for example between a smart card and a terminal). In order to help the reader understand these examples better and determine the usefulness of our idea Mike Bond and I have created a python simulation. This simulation allows you to choose the type of T-Box implementation, a direct or relay connection, as well as other parameters including the length of the anti-relay data stream and detection threshold.

In these two implementations we have restricted ourselves to make the T-Box part of the communication channel. The advantage is that we don’t rely on any party providing the T-Box since it is created automatically by communicating over the physical channel. The disadvantage is that a more powerful attacker can sample the line at twice the speed and overcome our T-Box solution.

The relay attack can be used against many applications, including all smart card based payments. There are already several ideas, including distance bounding, for detecting relay attacks. However our idea brings a new approach to the existing methods, and we hope that in the future we can find a practical implementation of our solutions, or a good scenario to use a physical T-Box which should not be affected by a powerful attacker.

The Internet is, by very definition, an interconnected network of networks. The resilience of the way in which the interconnection system works is fundamental to the resilience of the Internet. Thus far the Internet has coped well with disasters such as 9/11 and Hurricane Katrina – which have had very significant local impact, but the global Internet has scarcely been affected. Assorted technical problems in the interconnection system have caused a few hours of disruption but no long term effects.

But have we just been lucky ? A major new report, just published by ENISA (the European Network and Information Security Agency) tries to answer this question.

The report was written by Chris Hall, with the assistance of Ross Anderson and Richard Clayton at Cambridge and Panagiotis Trimintzios and Evangelos Ouzounis at ENISA. The full report runs to 238 pages, but for the time-challenged there’s a shorter 31 page executive summary and there will be a more ‘academic’ version of the latter at this year’s Workshop on the Economics of Information Security (WEIS 2011).
(more…)

The inaugural SATIN workshop was held at the National Physical Laboratory (NPL) on Monday/Tuesday this week. The workshop format was presentations of 15 minutes followed by 15 minutes of discussions — so all the 49 registered attendees were able to contribute to success of the event.

Many of the papers were about DNSSEC, but there were also papers on machine learning, traffic classification, use of names by malware and ideas for new types of naming system. There were also two invited talks: Roy Arends from Nominet (who kindly sponsored the event) gave an update on how the co.uk zone will be signed, and Rod Rasmussen from Internet Identity showed how passive DNS is helping in the fight against eCrime. All the papers, and the presenters slides can be found on the workshop website.

The workshop will be run again (as SATIN 2012), probably on March 22/23 (the week before IETF goes to Paris). The CFP, giving the exact submission schedule, will appear in late August.

Passwords are no longer acceptable as a security mechanism. The arrogant security people ask users that passwords be memorable, unguessable, high entropy, all different and never written down. With the proliferation of the number of passwords and the ever-increasing brute-force capabilities of modern computers, passwords of adequate strength are too complicated for human memory, especially when one must remember dozens of them. The above demands cannot all be satisfied simultaneously. Users are right to be pissed off.

A number of proposals have attempted to find better alternatives for the case of web authentication, partly because the web is the foremost culprit in the proliferation of passwords and partly because its clean interfaces make technical solutions tractable.

For the poor user, however, a password is a password, and it’s still a pain in the neck regardless of where it comes from. Users aren’t fed up with web passwords but with passwords altogether. In “Pico: no more passwords, the position paper I’ll be presenting tomorrow morning at the Security Protocols Workshop, I propose a clean-slate design to get rid of passwords everywhere, not just online. A portable gadget called Pico transforms your credentials from “what you know” into “what you have”.

A few people have already provided interesting feedback on the pre-proceedings draft version of the paper. I look forward to an animated discussion of this controversial proposal tomorrow. Whenever I serve as help desk for my non-geek acquaintances and listen to what drives them crazy about computers I feel ashamed that, with passwords, we (the security people) impose on them such a contradictory and unsatisfiable set of requests. Maybe your gut reaction to Pico will be “it’ll never work”, but I believe we have a duty to come up with something more usable than passwords.

[UPDATE: the paper can also be downloaded from my own Cambridge web site, where the final version will appear in due course.]

My paper Can We Fix the Security Economics of Federated Authentication? asks how we can deal with a world in which your mobile phone contains your credit cards, your driving license and even your car key. What happens when it gets stolen or infected?

Using one service to authenticate the users of another is an old dream but a terrible tar-pit. Recently it has become a game of pass-the-parcel: your newspaper authenticates you via your social networking site, which wants you to recover lost passwords by email, while your email provider wants to use your mobile phone and your phone company depends on your email account. The certification authorities on which online trust relies are open to coercion by governments – which would like us to use ID cards but are hopeless at making systems work. No-one even wants to answer the phone to help out a customer in distress. But as we move to a world of mobile wallets, in which your phone contains your credit cards and even your driving license, we’ll need a sound foundation that’s resilient to fraud and error, and usable by everyone. Where might this foundation be? I argue that there could be a quite surprising answer.

The paper describes some work I did on sabbatical at Google and will appear next week at the Security Protocols Workshop.