Slashdot Mirror
Stolen Adobe Passwords Were Encrypted, Not Hashed
rjmarvin writes "The hits keep coming in the massive Adobe breach. It turns out the millions of passwords stolen in the hack reported last month that compromised over 38 million users and source code of many Adobe products were protected using outdated encryption security instead of the best practice of hashing. Adobe admitted the hack targeted a backup system that had not been updated, leaving the hacked passwords more vulnerable to brute-force cracking."
Why is it that every single time some big entity's password database is breached, it turns out that they're not following best practices for password storage? Maybe I just don't remember the times when it hasn't been this way...
http://xkcd.com/1286/
Online security (or lack thereof) is one of the reasons it's a bad move to turn your Adobe Creative Suite into a cloud based subscription service.
Adobe admitted the hack targeted a backup system that had not been updated, leaving the hacked passwords more vulnerable to brute-force cracking.
Apparently even Adobe has trouble keeping up with updates and patches...what's the matter, get tired of the update server's nagging every couple of weeks?
I'm sure there's some irony to be found in this situation somewhere...
"I love animals! Some are cute, others are tasty, what's not to like?" - Betsy Schroeder, Jeopardy contestant
It wouldn't matter if users just followed best practices for password selection.
True, but that is only part of the story. There is also the email address used with Adobe. Users also need to exercise caution with links and attachments.
Last week I started to receive phishing emails on the unique email address that I had used with Adobe.
To expand on this - if the key doesn't leak, then Alice's password is 'safe' even if she reuses it on other sites only if nobody else in the Adobe dump has used her password, and that username is identifiable on other dumps of released passwords.
So, if Alice and Bob's passwords are identical, Bob's password has been recovered from elsewhere, you now know what Alice's password is, and password reuse becomes risky.
While poor practice as if the encryption key can be recovered _everyones_ password is now released - for 3DES as I understand it - if a long key has been used, there is no practical attack against it.
So, yes, if you have another list of passwords, you can go and say 'Bob used password 1223 on these two other releases, if he's used 1223 for Adobe - here are all the other people who've used that same password' - but you can't recover passwords not shared by other people who have not had their passwords leaked already.
Massive computation buys you nothing here, unless you can crack the key, which for a long random key is impractical.
In this case, 3DES may have leaked less data that is important.
Close. '123456' tops Adobe password list.
Also, I know this doesn't need a reference, but just for those who like a good nostalgic laugh.
Why is it that every single time some big entity's password database is breached, it turns out that they're not following best practices for password storage? Maybe I just don't remember the times when it hasn't been this way...
I've lost my copy of "The Big Book of Best Practices" and would like to purchase a new copy.
It's not on Amazon or eBay - would you sell me your copy?
(Or alternately, point me to the content for chapter 6: "Best Practices for Security in IT".)
The passwords are very breakable as they used the same IV's and keys for every password. Thus any two same plain texts have the same cipher text. A little, simple statistical analysis will get you the keystream and allow you to get all the plain text passwords.
People who use "best practices for passwords" have passwords that are so brutally hard to remember for a human being that they end up having to 'save' it on a Post-It note stuck to the side of their monitor or "hidden" under a pile of papers that others can look at. Or relegate the 'remembering' of their passwords to another piece of software like a system wallet/keychain, which is just offloading responsibility to another system that itself is an unknown quantity with respect to being well written. But even if a user uses a wallet/keychain, that doesn't remove the Post-It note vector if they need to use the password on more than one piece of hardware. It or a text file on a thumb drive are the common ways to transfer these kinds of passwords between devices.
The reality of how the average person uses a computer often does not reflect the theories that many so called computer security experts have. That is because the latter forget that they are not in the center of the human standard normal curve. Most people don't think like programmers or so called security experts. Better to make the system secure than rely on people to follow so called password best practices. If it isn't easy for the average user, they won't use it.
-- I ignore anonymous replies to my comments and postings.
According to Adobe, until a year ago, they were doing it wrong, using the wrong encryption in the wrong way.
The bad guys got a year-old backup, so it was encrypted using the old (wrong) method.
Since the old backup is done wrong, that tells us only that the primary USED TO be done wrong, which is exactly what Adobe is saying. It tells us nothing about the current database.
I haven't checked, but I assume my own Adobe account was part of this leak. And I don't care.
Along with a large portion of the increasingly savvy population, I have more than one "level" of password in use. My account used the lowest of these, basically something like adobe_123. Learning that is not going to help anyone form useful heuristics on how I create my banking passwords -- it might even poison them.
On the whole, I believe the breach will probably help crackers (if decryption can be achieved). But, I think it is foolish to automatically assume that accounts with "weak" passwords are contributors to the problem. As with me, they might be poor indicators of how humans choose more important passwords.
Of the 12,000 or so sites I've seen, well over 90% do it wrong. I'd estimate 95%. Many store passwords in plain text.
Most use 3DES, which was reasonably secure in 1972. Today, 3DES is cracked in milliseconds.
Sometimes we see an unsalted hash, including MD5.
A few have used MySQL's PASSWORD() and the phpass gimmick scheme which are reasonably secure but non-portable.
I consider "doing it right" to be a salted hash. For new software, bcrypt / blowfish or a SHA primitive.
Preferably, SHA-256 or SHA-512 via crypt($5$salt$, password) for portability and consistency.
For existing code, I consider SALTED MD5 to be acceptable, but the length of the input should certainly be validated.
SHA-2 includes both SHA-256 and SHA-512. Password hash algorithms generally use repeated iterations to slow brute force attacks. For instance, crypt modular hashes use $5$rounds=....$ and $6$rounds=...$ as the prefix for these hashes (respectively) to indicate which type and the number of iterations.
As far as I know, they're currently fairly solid for the purpose of hashing passwords, but CPU/GPU power marches on.
If I have been able to see further than others, it is because I bought a pair of binoculars.
SHA-2, aka SHA256 or SHA512.
http://en.wikipedia.org/wiki/SHA-2
The more you know....
In practice hashing is often much less secure than encryption for passwords. The devil is in the details.
Here it seems that Adobe made some poor design choices in the encryption algorithm. Yet, despite these flaws, assuming the encryption key is not compromised they might still be better off with their encryption rather than a poor hash mechanism such as the one used for example by Sony and revealed in the playstation hack by anonymous.
In general if the encryption key is not compromised, then encryption provides much more security than pure hashing, or even hashing with a salt. The reason for that is that with encryption, the security of the password depends on the strength of the secret key. With hashing, the security depends of the strength of the password. This is a significant difference. So, if your password is 4 characters long, even the best hash algorithm will fail to protect from a brute force attack. However, if that same password is encrypted, you need to brute force the key which would take centuries assuming the key is long enough.
To be more precise:
1) Pure hashing (applying SHA1 alone for example) is almost the same as having no security at all.
2) Hashing with a salt is a bit better but still won't resist long given computational power offered by GPUs and cloud computing.
3) An iterated hash function with a salt is much better (see PKDF2), and buys you some security but still vulnerable from brute force attacks using GPUs and pooled cloud resources.
4) A "sequential memory-hard" hash function (with salt and iteration) such as "scrypt" is pretty safe today.
Unfortunately in reality most companies use either (1) or (2)...
The drawback of encryption is that you need to make sure that your key is safe. Once the key is compromised you're toast. This means that you should not put the key on the same system that is hosting the password database (it may sound evident, but I've seen it done). It requires putting the key in a HSM (Hardware Security Module) or in a distinct ultra secure server, distinct from the password database.
Of course, if you have the possibility to keep a key secure, the best option is to use a *keyed* hash function (an iterated salted version of HMAC for example), getting the benefits of both worlds...
even xkcd beats Slashdot to a story.
Here is the essential part missing from the summary:
magnet:?xt=urn:btih:441582b9204dad5a26199aa51c7746d641f95b21&dn=users.tar.gz&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Fopen.demonii.com%3A1337
The file is called users.atr.gz, and is 4 GB.
As already shown by http://xkcd.com/1286/ , this looks like a fun project for a lonely rainy week-end...
You could do both: Hash and encrypt.
No, I explained why when I talked about establishing proof of password knowledge.
Entering your password into a site which falsely claims to be twitter or facebook or google or whatever should NOT result in compromise of your password. It should instead result in detection of a scam (e.g. failure to connect to site)
Entering passwords into plaintext web forms on SSL sites obviously does NOT accomplish this.
Being trained to entering passwords only into browser based login dialogue which mutually authenticates using appropriate zero knowledge proof does.
All mutual authentication requires guarding of source of trust. You can hash a password and store the hash but this only shifts the burden from protecting the password to protecting the hash. If the hash is compromised trust is also compromised (e.g. "passing the hash"). There is fundamentally no way around it other than to maintain the current ridiculous status quot.
If you only use hashing then, yes, you are open to Rainbow Table attacks because common passwords can be immediately exposed.
But hashing is not salted hashing. Best practice uses salted hashing with a unique salt for each user, thus making Rainbow Table attacks useless - you have to generate a whole new set of Rainbow Tables for each known salt which is a whole lot more work for an attacker.