Ashley Madison's data breach is everyone's problem

[Audrey McNeil <audrey () riskbasedsecurity com>]

http://www.theverge.com/2015/7/20/9006213/ashley-madisons-data-breach-is-everyones-problem

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 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?

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.

_______________________________________________
Dataloss Mailing List (dataloss () datalossdb org)
Archived at http://seclists.org/dataloss/
Unsubscribe at http://lists.osvdb.org/mailman/listinfo/dataloss
For inquiries regarding use or licensing of data, e-mail
        sales () riskbasedsecurity com 

Supporters:

Risk Based Security (http://www.riskbasedsecurity.com/)
YourCISO is an affordable SaaS solution that provides a comprehensive information security program that ensures focus 
on the right security.  If you need security help or want to provide real risk reduction for your clients contact us!