Adobe customer data breached
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 any 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.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/XjzDtw9sOqQ/