Sponsored by:

Your affairs were never discreet – Ashley Madison always disclosed customer identities

I always find data breaches like today’s Ashley Madison one curious in terms of how people react. But this one is particularly curious because of the promise of “discreet” encounters:

Ashley Madison is the world's leading married dating service for discreet encounters

Of course when the modus operandi of the site is to facilitate extramarital affairs then “discreet” is somewhat of a virtue… if they actually were discreet about their customers’ identities! This all made me think back to the Adult Friend Finder breach of a couple of months ago. Once that one hit the public air, I proceeded to load the data into Have I been pwned? as I usually do after a data breach has gone public and then… I got a couple of emails. Emails like this:

My association with that service (AFF) is private, is it possible to remove my email from that list, or change it’s association to another breach?

And a somewhat less polite one:

Please remove my email from your database IMMEDIATELY



Otherwise, I will seek legal counsel.

Now I’ve never received this sort of email before and I’ve never received one since, but something poignant struck me – these guys think that their presence on the site was only disclosed because of a data breach! Let me show you how fundamentally wrong that thinking is courtesy of Ashley Madison.

Let’s take their password reset form:

Forgot password page on Ashley Madison

Now before you say “Ah, I see where this is going”, stick with me because this one has an interesting twist. Clearly, in the form above I have entered an invalid email address. Nine times out of ten, you submit this form and the site explicitly tells you that the email address doesn’t exist thus exposing when an email address does exist courtesy of a different response message. But Ashley Madison is different, it does this:

Ashley Madison saying an email will be sent if the account exists

Now this is good because it doesn’t deny the presence of the account. When I first saw this, I wondered if perhaps there may be a possible timing attack, that is if the response above wasn’t sending an email yet for a legitimate account it was sending one, could there be an observable delay in response times? So I created a test account and tried to reset that password which resulted in this message:

Thank you for your forgotten password request. If that email address exists in our database, you will receive an email to that address shortly

Which is good, right? Same response message as the invalid account thus not disclosing the presence of the legitimate one. This is the correct defence for what we’d otherwise know as an account enumeration risk. Except, well, let me illustrate this second response visually:

Missing input box when the account exists

Get it? Compare the images – it’s the same message, but the text box and send button have been removed! The developers somehow managed to snatch enumeration defeat from the hands of victory!

So here’s the the lesson for anyone creating accounts on websites: always assume the presence of your account is discoverable. It doesn’t take a data breach, sites will frequently tell you either directly or implicitly. Moral judgement about the nature of these sites aside, members are entitled to their privacy. If you want a presence on sites that you don’t want anyone else knowing about, use an email alias not traceable back to yourself or an entirely different account altogether.

For developers, if you’re interested in the nuances of managing accounts such that you’re not falling victim to a myriad of traps like this, check out my Secure Account Management Fundamentals course on Pluralsight. None of this is hard, yet somehow these flaws are just all over the place.

Security Ashley Madison