This website does readability filtering of other pages. All styles, scripts, forms and ads are stripped. If you want your website excluded or have other feedback, use this form.

Adobe customer data breached – login and credit card data probably stolen, all passwords reset – Naked Security

Skip to content

Naked Security

Computer Security News, Advice and Research
Award-winning computer security news

Adobe customer data breached – login and credit card data probably stolen, all passwords reset

04 Oct 2013 14 Adobe, Cryptography, Data loss, Privacy by Paul Ducklin

Today, it’s Adobe’s turn to attend confession.

The multimedia giant has owned up to getting pwned, admitting that “attackers illegally entered our network”:

We recently discovered that attackers illegally entered our network. The attackers may have obtained access to your Adobe ID and encrypted password. We currently have no indication that there has been unauthorized activity on your account. If you have placed an order with us, information such as your name, encrypted payment card number, and card expiration date also may have been accessed. We do not believe any decrypted card numbers were removed from our systems.

To prevent unauthorized access to your account, we have reset your password... We recommend that you also change your password on any website where you use the same user ID or password. As always, please be cautious when responding to any email seeking your personal information.

Not a happy time for Adobe – one of the problems you face after you realise you’ve suffered a breach is working out what the crooks did while they were at large in your network.

If you are the victim of a break-and-enter at home, it’s often fairly obvious what happened: the TV-shaped hole in your entertainment centre cabinet, for example, is a glaring clue.

Even if you don’t know immediately what’s missing, it’s often possible to make a reasonably accurate inventory afterwards – passport? wallet? watch? – and react accordingly.

Network breaches aren’t like that, not least because when data is stolen, you still have your own copy.

→ Pedants may point out that “to steal” means “to take someone else’s property unlawfully without intending to return it”, but here I use the word unapologetically. You know what I mean.

Worse still, since the crooks bypassed your security to get in, they may have bypassed your security while they were in, so you can’t even be sure whether you can trust your logs.

So I feel Adobe’s pain, as they’ve had to make a very general admission, and reset everyone’s password, even though it may turn out that not much in the way of unencrypted Personally Identifiable Information (PII) was taken during the intrusion.

But that’s cold comfort for people who have bought from Adobe recently.

Some notes about the disclosure

Just a couple of points of things I suggest that Adobe could and should have done differently in the disclosure.

• “The attackers may have gained access to your… encrypted password.”

The devil’s in the details. Technically, the passwords probably weren’t encrypted, which would imply that Adobe could decrypt them and thus learn what password you had chosen.

Today’s norms for password storage use a one-way mathematical function called a hash that pretty much uniquely depends on the password, so that you can calculate the hash from the password, but not the other way around.

This means that you never actually store the password at all, encrypted or not: the user reveals the password on login, but you only ever need to process it in memory to verify the hash, so it need never be saved to disk.

Of course, that means that crooks could produce a giant table of hashes for popular passwords, thus speeding up their attacks, so you also usually add some salt: a random string that you store with the user’s ID and mix into the password when you compute the hash.

Even if two users choose the same password, their salts will be different, so they’ll end up with different hashes, which makes things much harder for an attacker.

And, lastly, you don’t usually just apply the hash function once to the salt-and-password combination.

You use some sort of key derivation function (KDF) that does a lot more than just a single hash calculation, so you slow down any attempt by someone who has stolen your database to try a long list of passwords one-by-one. (This is sometimes called key stretching, for obvious metaphorical reasons.)

Common KDFs used with salting-and-hashing are PBKDF2, bcrypt and scrypt. They are typically used so it takes 10,000 times longer, or more, to check each password than a plain hash function would. This hinders attempts to crack passwords against a dictionary list without noticeably slowing down each legitimate login.

With all this in mind, it would have been nice to see Adobe state explicitly what salting, hashing and stretching algorithms were in use, even if only as an appendix to the breach notification.

That means that users could take their own advice about how likely it is that their stolen “encrypted password” could be worked out by an attacker.

• “Encrypted payment card number, and card expiration date.”

Maybe I am reading too much into this, but I interpret this sentence (and note carefully the comma before “and”) to mean that your card number was encrypted, but your expiry date was not.

My suspicion is reinforced by the later explicit remark that “decrypted card numbers” were probably not stolen.

Why not be perfectly clear?

If card numbers and expiry dates were both encrypted, say so explicitly.

If not, make it clear that the crooks now probably do have your expiry date, even though they may not have your full card number.

• “Change your password on any website where you use the same … password.”

How about making this advice much stronger?

If you are using the same password on other sites, don’t just go and change it.

Go and change it to something that is not the same as any other site, so that crooks who work out your password for one account don’t automatically get access to other parts of your online life, too.

That’s what we’re advising as one of our three “Do These 3” tips for Cybersecurity Awareness Month, because we think it’s important.

It would be nice to see Adobe treating it as important advice, too.

Listen to our “Do These 3” tips now in this short, special-issue podcast

(03 October 2013, duration 8’58”, size 5.4MB)

Before we go

By the way, one final reminder if you hold personal information about other people.

Encrypting credit card data and salting-hashing-and-stretching passwords are vital security protections.

But they are not a replacement for keeping the data safe in the first place – they’re a second layer, in case your first line of defence should fail.

Just saying.

Follow @duckblog

Free tools

Sophos Home
for Windows and Mac

Hitman Pro

Sophos Mobile Security
for Android

Virus Removal Tool

for Linux

About the author

Paul Ducklin

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too.

14 comments on “Adobe customer data breached – login and credit card data probably stolen, all passwords reset”

  1. "We do not believe any decrypted card numbers were removed from our systems."

    Which suggests that decrypted card numbers are stored somewhere on their system. Surely that's a breach of PCIDSS?

    • That occurred to me as well…but the numbers don't have to be stored to be stolen by determined crooks. These days, the crooks use so-called "RAM-scraping" malware to read card data out of memory while a transaction is being processed.

      Maybe what Adobe means is that "we haven't found any evidence of RAM scraping that could have exfiltrated your card number when you bought something."

      The choice of the word "decrypted", rather than "unencrypted", seems to suggest that Adobe is saying merely that no data was stolen while in use.

      Once again. clarity would have been nice.

  2. With a shout out to Brian Krebs and Alex Holden who discovered the breach, Mr. Krebs starts his writeup with the observation that source code was stolen for ColdFusion, possibly Acrobat and we don't know what else. Reader? Flash? AIR? Shockwave? Photoshop?

    3 million credit card records is an undeniably serious leak, but I am more concerned about the potential for future zero-day attacks if the source code for ColdFusion and possibly other extremely widely-used products is in the hands of sophisticated attackers.

    Adobe Reader and Flash are arguably two of the most commonly exploited "must-keep-patched" applications already, so the loss of any source code relating to them must be a huge blow for Adobe and a serious concern for the general computer-using population at large.

    • I guess I shall have to write about the source breach later, as you're not the only person to say, "Credit cards? Passwords? Small beer against all that source code!"

      My guy feeling, though, is quite the opposite. I feel for Adobe, victim as the company is of a giant crime. But its carelessness with its own intellectual property is its own lookout, while its carelessness with other people's PII is also *those people's* lookout.

      I hear you about "future zero days" now the source is stolen, but I am still undecided about how much difference the source is likely to make. Are there more 0-days in Firefox and Chromium, for instance, since they are open source, than in IE, where the source code is kept secret?

      (I accept that crooks trying to convert vulns into exploits in applications for which source has never before been available might find the hitherto unseen source code handy, at least for low hanging fruit. Might save lots of disassembly.)

      Assume that security through obscurity (closed source code, for example) doesn't improve security at all, and may even make it worse…that's a reasonably well-held opinion. If it's true, does removing said obscurity (opening up the source code, for example) *also* make security worse?

      • You certainly raise some interesting points Paul, and challenge my preconceptions — which is really why I read NakedSecurity in the first place.

        I would respond to your last question with the observation that opening up the source code to uninvited criminals is very different from opening it up as open source to the public at large; so we now have the worst of all worlds — obscurity of still-closed-source code known only to the owners and a team of people intending to exploit it. That can't be good.

        I suppose one could launch a study to look historically at other source code leaks to see whether the pattern of attacks or vulnerabilities changes noticeably afterwards. And I could just have easily argued that a known source code leak will cause a vendor to redouble their efforts in rigorous code review to take care of any low-hanging fruit themselves first.

        But really it's all academic. Let's just hope none of the worse cases transpire and that the end-users themselves suffer as little loss from this as possible.

        • Ah! I was hoping you might say that…*now* I agree with you! If there are 0-days that the source code will reveal to "fresh eyes" (i.e. not Adobe), then, indeed, the odds are stacked against us, because the only fresh eyes are going to be the crooks. Exactly as you say, the code is still closed source to the good guys (so no benefit), but open to the baddies (neutral outcome at best).

          Maybe Adobe could open up a bug bounty program for vulns found via source code, and let researchers sign up to get it legitimately, under some sort of light NDA.

          Not quite the whole open source hog, but at least balance out the "fresh eyes" of the crooks with some "fresh eyes" of reputable bug hunters?

          (Big corporate source code dumps are…well, less interesting than might at first be thought…most code is dulllllllll. When the NT sources got pwned years back, everyone waited for the wheels to come off, but they didn't. Not any more than usual, anyway 🙂

    • Ditto I got the warning email (Important Password Reset Information 6 Nov 2013), but when I went to change the Password it did not recognise me!

      The warning came from [email protected] – which is initially worrying, but
      – is according to Norton SafeWeb “OK”
      – netcraft confirm that [email protected] is the DNS admin for
      So I presume that it is genuine.

      The link in the email eventually dumps me at
      which again looks OK

      But if I enter the email address that they used to contact me, the page returns:
      The provided email address could not be matched to an account on file. Please try again.
      And suggests that I drop the “.uk” from my email address! (It does not match that email address either – not that I expected it to!)

      What is going on?

  3. I downloaded Adobe Reader about 10 days ago. I don't believe I have an Adobe password but I am not sure. How can I find out ?


    • Use a reputable anti-virus program – if it detects a bot/zombie, it should offer to clean it up, which is what you want.

      If you like, you can use the Sophos Virus Removal Tool for Windows (or Sophos Anti-Virus for Mac, if you are an OS X user) for free:


      (But beware of programs that do a virus scan for free but suddenly ask for money as soon as they find something – you should assume that sort of behaviour is a scam. Guess what? They inevitably "find" something 🙂

  4. Like LJT and Barbara above, I have used Adobe Reader via download for years, but never had an account or password that I am aware of. Now what???


Leave a Reply Cancel reply

Recommended reads