Monday, July 20, 2015
by Russell Brandom Late last night, the 37 million users of the adultery-themed dating site Ashley Madison got some very bad news. A group calling itself the Impact Team appears to have compromised all the company's data, and is threatening to release "all customer records, including profiles with all the customers' secret sexual fantasies" if Ashley Madison and a sister site are not taken down. Collecting and retaining user data is the norm in modern web businesses, and while it's usually invisible, the result for Ashley Madison has been catastrophic. In hindsight, we can point to data that should have been anonymized or connections that should have been less accessible, but the biggest problem is deeper and more universal. If services want to offer genuine privacy, they have to break away from those practices, interrogating every element of their service as a potential security problem. Ashley Madison didn't do that. The service was engineered and arranged like dozens of other modern web sites — and by following those rules, the company made a breach like this inevitable. The company made a breach like this inevitable The most obvious example of this is Ashley Madison's password reset feature. It works just like dozens of other password resets you've seen: you enter in your email, and if you're in the database, they'll send a link to create a new password. As developer Troy Hunt points out, it also shows you a slightly different message if the email really is in the database. The result is that, if you want to find out if your husband is looking for dates on Ashley Madison, all you have to do is plug in his email and see which page you get. That was true long before the hack, and it was a serious data leak — but because it followed standard web practices, it slipped by mostly unnoticed. It's not the only example: you could make similar points about data retention, SQL databases or a dozen other back-end features. This is how web development usually works. You find features that work on other sites and you copy them, giving developers a codebase to work from and users a head start in figuring out the site. But those features aren't usually built with privacy in mind, which means developers often import security problems at the same time. The password reset feature was fine for services like Amazon or Gmail, where it doesn't matter if you're outed as a user — but for an ostensibly private service like Ashley Madison, it was a disaster waiting to happen. Now that the company's database is on the cusp of being made public, there are other design decisions that may prove even more damaging. Why, for instance, did the site keep users' real names and addresses on file? It's a standard practice, sure, and it certainly makes billing easier — but now that Ashley Madison has been breached, it's hard to think the benefits outweighed the risk. As Johns Hopkins cryptographer Matthew Green pointed out in the wake of the breach, customer data is often a liability rather than an asset. If the service is meant to be private, why not purge all identifiable information from the servers, communicating only through pseudonyms? Customer data is often a liability rather than an asset The worst practice of all was Ashley Madison's "paid delete" service, which offered to take down user's private data for $19 — a practice that now looks like extortion in the service of privacy. But even the idea of paying a premium for privacy isn't new within the web more broadly. WHOIS offers a version of the same service: for an extra $8 per year, you can keep your personal information out of the database. The difference, of course, is that Ashley Madison is an entirely different kind of service, and should have been baking privacy in from the very beginning. It's an open question how strong Ashley Madison's privacy needed to be — should it have used Bitcoins instead of credit cards? insisted on Tor? — but the company seems to have ignored those issues entirely. The result was a disaster waiting to happen. There's no obvious technical failure to blame for the breach (according to the company, the attacker was an insider threat), but there was a serious data management problem, and it’s entirely Ashley Madison’s fault. Much of the data that's at risk of leaking should never have been available at all. But while Ashley Madison made a bad, painful error by openly retaining that much data, it’s not the only company that’s making that mistake. We expect modern web companies to collect and retain data on their users, even when they have no reason to. The expectation hits every level, from the way sites are funded to the way they're engineered. It rarely backfires, but when it does, it can be a nightmare for companies and users alike. For Ashley Madison, it may be that the company didn't truly consider privacy until it was too late.