Light Blue Touchpaper

Last weekend, my wife and I were in Milton Keynes where we bought a cradle as a present for our new granddaughter. They had only the demo model in the shop, but sold us one to pick up from their store in Cambridge. So yesterday I went into John Lewis with the receipt, to be told by the official that as I couldn’t show the card with which the purchase was made, they needed photo-id. I told him that along with over a million others I’d resisted the previous government’s ID card proposals, the last government had lost the election, and I didn’t carry ID on principle. The response was the usual nonsense: that I should have read the terms and conditions (but when I studied the receipt later it said nothing about ID) and that he was just doing his job (but John Lewis prides itself on being employee-owned, so in theory at least he is a partner in the firm). I won’t be shopping there again anytime soon.

We get harassed more and more by security theatre, by snooping and by bullying. What’s the best way to push back? Why can businesses be so pointlessly annoying?

Perhaps John Lewis are consciously pro-Labour given their history as a co-op; but it’s not prudent to advertise that in a three-way marginal like Cambridge, let alone in the leafy southern suburbs where they make most of their money. Or perhaps it’s just incompetence. When my wife phoned later to complain, the customer services people apologised and said we should have been told when we bought the thing that we’d need to show ID. She offered to post the cradle to our daughter, but then rung back later to say they’d lost the order and would need our paperwork. So that’s another 30-mile round-trip to their depot. But if they’re incompetent, why should I trust them enough to buy their food?

I invite the chairman, Charlie Mayfield, to explain by means of a follow-up to this post whether this was policy or cockup. Will he continue to demand photo-id even from customers who have a principled objection? Will he tell us who in the firm imposed this policy, and show us the training material that was prepared to ensure that counter staff would explain it properly to customers?

Research in the Security Group has uncovered various flaws in systems, despite them being certified as secure. Sometimes the certification criteria have been inadequate and sometimes the certification process has been subverted. Not only do these failures affect the owners of the system but when evidence of certification comes up in court, the impact can be much wider.

There’s a variety of approaches to certification, ranging from extremely generic (such as Common Criteria) to highly specific (such as EMV), but all are (at least partially) descendants of a report by Willis H. Ware – “Security Controls for Computer Systems”. There’s much that can be learned from this report, particularly the rationale for why certification systems are set up as the way they are. The differences between how Ware envisaged certification and how certification is now performed is also informative, whether these differences are for good or for ill.

Along with Mike Bond and Ross Anderson, I have written an article for the “Lost Treasures” edition of IEEE Security & Privacy where we discuss what can be learned, about how today’s certifications work and should work, from the Ware report. In particular, we explore how the failure to follow the recommendations in the Ware report can explain why flaws in certified banking systems were not detected earlier. Our article, “How Certification Systems Fail: Lessons from the Ware Report” is available open-access in the version submitted to the IEEE. The edited version, as appearing in the print edition (IEEE Security & Privacy, volume 10, issue 6, pages 40–44, Nov‐Dec 2012. DOI:10.1109/MSP.2012.89) is only available to IEEE subscribers.

Today the UK Information Commissioner’s Office levied a record £250k fine against Sony over their 2011 Playstation Network breach in which 77 million passwords were stolen. Sony stated that they hashed the passwords, but provided no details. I was hoping that investigators would reveal what hash algorithm Sony used, and in particular if they salted and iterated the hash. Unfortunately, the ICO’s report failed to provide any such details:

The Commissioner is aware that the data controller made some efforts to protect account passwords, however the data controller failed to ensure that the Network Platform service provider kept up with technical developments. Therefore the means used would not, at the time of the attack, be deemed appropriate, given the technical resources available to the data controller.

Given how often I see password implementations use a single iteration of MD5 with no salt, I’d consider that to be the most likely interpretation. It’s inexcusable though for a 12-page report written at public expense to omit such basic technical details. As I said at the time of the Sony Breach, it’s important to update breach notification laws to require that password hashing details be disclosed in full. It makes a difference for users affected by the breach, and it might help motivate companies to get these basic security mechanics right.

Computers are getting exponentially faster, yet the human brain is constant! Surely password crackers will eventually beat human memory…

I’ve heard this fallacy repeated enough times, usually soon after the latest advance in hardware for password cracking hits the news, that I’d like to definitively debunk it. Password cracking is certainly getting faster. In my thesis I charted 20 years of password cracking improvements and found an increase of about 1,000 in the number of guesses per second per unit cost that could be achieved, almost exactly a Moore’s Law-style doubling every two years. The good news though is that password hash functions can (and should) co-evolve to get proportionately costlier to evaluate over time. This is a classic arms race and keeping pace simply requires regularly increasing the number of iterations in a password hash. We can even improve against password cracking over time using memory-bound functions, because memory speeds aren’t increasing nearly as quickly and are harder to parallellise. The scrypt() key derivation function is a good implementation of a memory-bound password hash and every high security application should be using it or something similar.

The downside of this arms race is that password hashing will never get any cheaper to deploy (even in inflation-adjusted terms). Hashing a password must be as slow and costly in real terms 20 years from now or else security will be lower. Moore’s Law will never reduce the expense of running an authentication system because security depends on this expense. It also needs to be a non-negligible expense. Achieving any real security requires that password verification take on the order of hundreds of milliseconds or even whole seconds. Unfortunately this hasn’t been the experience of the past 20 years. MD5 was launched over 20 years ago and is still the most common implementation I see in the wild, though it’s gone from being relatively expensive to evaluate to extremely cheap. Moore’s Law has indeed broken MD5 as a password hash and no serious application should still use it. Human memory isn’t more of a problem today than it used to be though. The problem is that we’ve chosen to let password verification become too cheap.

Last week, I gave a talk at the Center for Information Technology Policy at Princeton. My goal was to expand my usual research talk on passwords with broader predictions about where authentication is going. From the reaction and discussion afterwards one point I made stood out: authenticating humans is becoming a machine learning problem.

Problems with passwords are well-documented. They’re easy to guess, they can be sniffed in transit, stolen by malware, phished or leaked. This has led to loads of academic research seeking to replace passwords with something, anything, that fixes these “obvious” problems. There’s also a smaller sub-field of papers attempting to explain why passwords have survived. We’ve made the point well that network economics heavily favor passwords as the incumbent, but underestimated how effectively the risks of passwords can be managed in practice by good machine learning.

From my brief time at Google, my internship at Yahoo!, and conversations with other companies doing web authentication at scale, I’ve observed that as authentication systems develop they gradually merge with other abuse-fighting systems dealing with various forms of spam (email, account creation, link, etc.) and phishing. Authentication eventually loses its binary nature and becomes a fuzzy classification problem. (more…)

It’s not unusual for banks to send emails which are confusingly similar to phishing, but this recent one I received from Virgin Money is exceptionally bad. It tells customers that the bank (Northern Rock) is changing domain names from their usual one (northernrock.co.uk) to virginmoney.com and customers should use their usual security credentials to log into the new domain name. Mail clients will often be helpful and change the virginmoney.com into a link.

This message is exactly what phishers would like customers to fall for. While this email was legitimate (albeit very unwise), a criminal could follow up with an email saying that savings customers should access their account at virginsavings.net (which is currently available for registration). Virgin Money have trained their customers to accept such emails as legitimate, which is a very dangerous lesson to teach.

It would have been safer to not do the rebranding, but if that’s considered essential for commercial reasons, then customers should have been told to continue accessing the site at their usual domain name, and redirected them (via HTTPS) to the new site. It would mean keeping hold of the Northern Rock domain names for the foreseeable future, but that is almost certainly what Virgin Money are planning anyway.

[larger version]

(post UPDATED with new job opening)

I am delighted to announce a job opening in the Cambridge Security Group. Thanks to generous funding from the European Research Council I am in a position to recruit several post-doc research associates to work with me on the Pico project, whose ambitious aim is ultimately to liberate the world from the annoyance and insecurity of passwords, which everyone hates.

In previous posts I hinted at why it’s going to be quite difficult (Oakland paper) and what my vision for Pico is (SPW paper, USENIX invited talk). What I want to do, now that I have the investment to back my idea, is to assemble an interdisciplinary team of the best possible people, with backgrounds not just in security and software but crucially in psychology, interaction design and embedded hardware. We’ll design and build a prototype, build a batch of them and then have real people (not geeks) try them out and tell us why they’re all wrong. And then design and build a better one and try it out again. And iterate as necessary, always driven by what works for real humans, not technologists. I expect that the final Pico will be rather different, and a lot better, than the one I envisaged in 2011. Oh, and by the way, to encourage universal uptake, I already promised I won’t patent any of it.

As I wrote in the papers above, I don’t expect we’ll see the end of passwords anytime soon, nor that Pico will displace passwords as soon as it exists. But I do want to be ready with a fully worked out solution for when we finally collectively decide that we’ve had enough.

Imagine we could restart from zero and do things right. Have you got a relevant PhD or are about to get one? Are you keen to use it to change the world for the better? Are you best of the best, and have the track record to prove it? Are you willing to the first member of my brilliant interdisciplinary team? Are you ready for the intellectually challenging and stimulating environment of one of the top research universities in the world? Are you ready to be given your own real challenges and responsibilities, and the authority to be in charge of your work? Then great, I want to hear from you and here’s what you need to do to apply (post UPDATED with new opening).

(By the way: I’m off to Norway next week for passwords^12, a lively 3-day conference organized by Per Thorsheim and totally devoted to nothing else than passwords.)

There was a public outcry followed by ICO “making enquiries” when Troy Hunt published a post about Tesco’s plaintext password reminders exactly a month ago.

I wanted to use the reference for a text I was writing last week when someone asked me about online accounts of Companies House. At that moment I said to myself, wait a second. Companies House sends plaintext reminders as well. How strange. I sent a link to a short post to ComputerWorld. They in turn managed to get a statement from Companies House that includes:

“… although it is [Companies House] certified to the ISO 27001 standard and adheres to the government’s Security Policy Framework, it will carry out a review of its systems in order to establish whether there is a threat to companies’ confidential information.” (more…)

Yesterday, I took a critical look at the difficulty of interpreting progress in password cracking. Today I’ll make a broader argument that even if we had good data to evaluate cracking efficiency, recent progress isn’t a major threat the vast majority of web passwords. Efficient and powerful cracking tools are useful in some targeted attack scenarios, but just don’t change the economics of industrial-scale attacks against web accounts. The basic mechanics of web passwords mean highly-efficient cracking doesn’t offer much benefit in untargeted attacks. (more…)

Password cracking has returned to the news, with a thorough Ars Technica article on the increasing potency of cracking tools and the third Crack Me If You Can contest at this year’s DEFCON. Taking a critical view, I’ll argue that it’s not clear exactly how much password cracking is improving and that the cracking community could do a much better job of measuring progress.

Password cracking can be evaluated on two nearly independent axes: power (the ability to check a large number of guesses quickly and cheaply using optimized software, GPUs, FPGAs, and so on) and efficiency (the ability to generate large lists of candidate passwords accurately ranked by real-world likelihood using sophisticated models). It’s relatively simple to measure cracking power in units of hashes evaluated per second or hashes per second per unit cost. There are details to account for, like the complexity of the hash being evaluated, but this problem is generally similar to cryptographic brute force against unknown (random) keys and power is generally increasing exponentially in tune with Moore’s law. The move to hardware-based cracking has enabled well-documented orders-of-magnitude speedups.

Cracking efficiency, by contrast, is rarely measured well. Useful data points, some of which I curated in my PhD thesis, consist of the number of guesses made against a given set of password hashes and the proportion of hashes which were cracked as a result. Ideally many such points should be reported, allowing us to plot a curve showing the marginal returns as additional guessing effort is expended. Unfortunately results are often stated in terms of the total number of hashes cracked (here are some examples). Sometimes the runtime of a cracking tool is reported, which is an improvement but conflates efficiency with power. (more…)