Stolen Adobe Passwords Were Encrypted, Not Hashed 230
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."
Am I imagining it? (Score:5, Insightful)
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...
Re: (Score:2)
Why do they always lie about it as well, even once found out? They say the backup was using an older and less secure system, but if the primary copy was hashed there would be no way to reverse it and then encrypt the original password anyway. Therefore we know that the primary password storage is always encrypted, and just as weak.
Re: (Score:2)
I believe what they are saying is that they did upgrade to hashes, but they had an old Dev environment from before the upgrade and that's what they hacked. I'd say that's pretty typical of big IT shops. Bunches of old Dev environments that go back years because people are afraid to erase them "just in case" Most companies have the false impression that the only part of their data that's at risk is the publicly facing stuff. They never think of "What if they get inside?"
Re: (Score:2)
It means it USED to be "encrypted", a year ago (Score:3)
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.
Re: (Score:2)
Hashing doesn't help that much with a database this large.
Simply check the 38 million for "password", "secret", and the username. Guaranteed to have an enormous amount of successful hits that way.
I wouldn't be surprised if a million were trivially breakable in this manner, in just a few minutes if not less. If you can make $1 from each, that's a nice chunk of cash you just got.
Re:Am I imagining it? (Score:4, Informative)
Hashing + Salting = Problem Solved.
Re:Am I imagining it? (Score:5, Insightful)
Nope, not solved. All it means is that the 100000 morons using "password" as the password won't have the same hash. So the attackers won't be able to find out which accounts share the same password and focus on those, and won't be able to use a pre-computed dictionary.
It is however trivial to hash "password" 38 million times for each salt, on modern hardware probably in seconds.
The salting does provide an improvement, but when you have 38 million accounts, breaking even 1% already gives you a huge amount of successes. Salting doesn't do much against checking the list against the 100 best known passwords. 3800 million is a small number for a GPU accelerated password cracker.
Wouldnt they hash the username and password? (Score:2)
Or even the username, customer number, and password? I mean you want as much in the stew as possible right? Then add a little salt to taste.
Re:Am I imagining it? (Score:5, Informative)
There's another major difference, for large password-database leaks. Salted hashes can't be computed for all leaked passwords at the same time, they need to be computed once per salt. That means that cracking the whole password database at once is, computationally, just as hard as cracking each password individually. With unsalted hashes, cracking the whole password database is as hard as cracking a single password. With this password database, that's a difficulty difference of a factor of 30 million, which is pretty substantial.
Re: (Score:2)
Not really. You could still test all users against the top 100 passwords in a reasonable amount of time. After that, test if their mail accounts have the same password.
It won't get you all user passwords, but the low hanging fruit / naive / non-tech-savvy users are probably a better target anyway
Re: (Score:2)
>Hashing + Salting = Problem Solved.
Not against brute force password attacks.
The lack of salt give benefit to the attacker when there are many passwords (which there are in this case). But the attacker can still take the salt and hash output and brute force the password space for any individual entry in the database.
Hashing + Salting + a symmetric secret = Problem Solved.
Re: (Score:2)
Simply check the 38 million for "password", "secret", and the username
If I have a password on file at Adobe (and I think I do), it's probably "password". And that's not a bad thing.
My email there is probably some variation of dontSpamMe@spam.la (that was such a wonderful service while it lasted); or some throwaway like adobespam@[my-own-domain].com.
And there's no way I ever gave them a credit card (or real name, etc).
TL/DR: password=password doesn't neccessarily imply insecure
Re: (Score:2)
Not for YOU. But it sure helps decrypt everyone else's password once you can analyze a know good value. Which is exactly what happened with Adobe's database.
Re: (Score:3)
Re: (Score:2)
... and my current pet peeve are entities that have an upper limit to password length within the current range of rainbow-table attacks
Do people still use rainbow tables. I was under the impression that they become prohibitively large after a certain length. I've not seen too many sites that don't let you go to at least 10 characters. That should get you out of the realm of rainbow tables.
Re: (Score:2)
Because if Adobe had no way of decrypting the passwords, they wouldn't be able to provide them to the NSA.
Re: (Score:2)
Because when a company follows best security practices it does not have its data breached in the first place.
Re: (Score:2)
Where are they listed? (Score:3)
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".)
Re:Where are they listed? (Score:5, Insightful)
https://www.owasp.org/index.php/Main_Page [owasp.org]
Re:Am I imagining it? (Score:5, Insightful)
Security team says such and such isn't secure.
Management says "Oh no! We have to do something"
Security provides a quote for the upgrade project.
Management asks "Um... what? Really? That's our entire 2013 development budget! What kind of fines are we looking at if there's a breach?"
Security: "Well... None..."
Management "So why is it you're in my office?"
Re: (Score:3)
Re: (Score:3)
Honest answer? 'Good enough' costs far less than 'really secure', and companies aren't really interested in doing any real security -- just something which looks secure-ish.
Worst case, they'll get a small fine which is less than the cost of making the changes would have been.
There's simply no incentive (because there are no real punishments) for a com
Re: (Score:2)
I suspect a lot of people setting these sites up don't even know what the best practices are. Or they don't know in the initial deployment and once that's done no force on earth will allow management to toss it out for a redesign.
A company next door to us once had all their user passwords in a plain text file, for 32 million users. The tech people advised the CEO that it needed changing but nothing was done. It was not considered important. So the inevitable leak happened and the business shrunk tremend
90%+ do it wrong - plain text or 3DES from 1972 (Score:3)
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 cryp
Re: (Score:2)
Re: (Score:2)
The problem is that the company has to now that there is an important security issue to be solved, and then hire someone that understands the issues. If they just head to the software team and say "make sure passwords are safe" then the twenty-something who's put on the job won't know what to do or how to do it.
I meant DES, default for crypt(), htpasswd (Score:2)
Thank you for the correction.
I meant DES, not 3DES. Most use crypt(random), htpasswd, or compatible.
* Not to be confused with crypt($5$salt$), which is secure SHA-256.
Re: (Score:2)
it turns out that they're not following best practices for password storage
Because sometimes, these systems have to interoperate with other systems that don't follow best practices. For example, if system A has to interact with system B on the user's behalf without the user's interaction, system A has to store some sort of token to authenticate to system B.
Re: (Score:2)
I was utterly amazed once when my Mac and Windows password from a few month previously was emailed to me in plain text from a third party site that was handling our company's online training. Just so much of that was ... wrong. Plain text mailing of a password that was once in use and may still be in use is idiotic. Plus the fact that somehow these passwords are in plain text on the corporate network somewhere, probably in the bowels of active directory. Plus that someone in IT decides that it's ok to s
Re: (Score:2)
Encrypting a password doesnt have to be an issue, if you use the password hash + username as the key for encrypting the password. There could be reasons to do it that way, and AFAICT it would be functionally identical to hashing with salt-- in either case a weak password would fall to brute-force, in either case you need to crack the passwords one at a time (due to the "salt").
The benefit of doing so is for instance if you wanted to encrypt user data with a key without giving said key to the vendor (adobe)
Re: (Score:2)
Relax, it's always been this way. IMHO it's because in the real world almost nobody - no company, and no person - follows best practices of today. At best they're running two or three years behind as the information soaks in through the semipermeable membrane of information flow through the folks who actually read up on this stuff daily, through their awareness, through mentions in group and company meetings every three months or so, into the IT management's headspace, into the implementation plan that is
Re: (Score:2)
Re:Am I imagining it? (Score:5, Insightful)
Are you blaming the users now? In any normal distribution of users, there will be some with good password policies, and some who don't have good password policies.
However, the company is entrusted with the password, and need to maintain good stewardship of it.
This is not good stewardship no matter how much you are trying to shift the blame to the users.
Re: (Score:3)
Are you blaming the users now? In any normal distribution of users, there will be some with good password policies, and some who don't have good password policies.
However, the company is entrusted with the password, and need to maintain good stewardship of it.
This is not good stewardship no matter how much you are trying to shift the blame to the users.
People were putting their actual passwords in the "Password Hint" field. I can certainly blame a user for doing that, as well as the developers for allowing it.
Re:Am I imagining it? (Score:5, Insightful)
There shouldn't be a Password Hint field.
Re:Am I imagining it? (Score:5, Interesting)
Re: (Score:2)
What I would like is some standardized way for recovering an account, but something decentralized, so one site doesn't hold the keys to everyone's city.
Maybe some option of signing a nonce with one's private key, using a OTP keyfob, or reading a text message, or perhaps a combination of the above might be good.
I've wondered about an "oh shit" recovery key. This would be a USB dongle that only receives power from the USB port, since it would not need a battery. It would be similar to the old SecurID "calcu
Re: (Score:2)
Sorry to disagree, but I feel there SHOULD be a password hint field. I also, however, feel that it should be encrypted. And that it shouldn't be allowed to contain the password.
Re:Am I imagining it? (Score:5, Insightful)
In this case, which would be easier?
1. Getting 38 million people to follow best practices?
2. Getting Adobe to follow best practices?
It's a question of scalability.
Re:Am I imagining it? (Score:5, Funny)
Re:Am I imagining it? (Score:5, Funny)
It's funny because bicubic
Re: (Score:2)
It's like the idea that if a bear starts chasing you and another person. You don't have to outrun the bear, just the other person.
And to be extra paranoid, I have a
Re: (Score:2)
And to be extra paranoid, I have a credit card that allows me to create temporary CC numbers that are only valid at one location for a certain dollar amount. This way Credit Card information can't be reused anywhere else either.
I have been surprised that this has not become the norm. What CC company are you using that has this feature?
Re: (Score:2)
Phishing going on too (Score:5, Interesting)
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.
Re: (Score:2)
Users also need to exercise caution
There will never be a phrase in computing history which has never been more heavily disregarded.
Re: (Score:2)
It doesn't help that a lot of sites use policies that make it harder to practice good password habits. Examples:
Re:Am I imagining it? (Score:4, Informative)
It wouldn't matter if users just followed best practices for password selection.
It still matters. First, badly chosen passwords are made _obvious_ to hackers; when two or three or a dozen people choose the same password that's a high probability that the password was bad in the first place. And second, losing 30 million passwords makes brute force worthwhile. If you have an algorithm that would crack one password in 30 years on average, it will find passwords in a set of 30 million at a rate of one every minute.
Re: Am I imagining it? (Score:2)
You Mean Using Post It Notes (Score:5, Interesting)
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.
Re: (Score:3)
I have a single password (8 mixed case alphanumeric characters) that I use as the base password. I then use a very simple algorithm (if you can call it that) that adds [certain] letters from the website's domain to the beginning and end of the base password. That way I have a different password for every site, but only have to remember a single password.
I've suggested it to quite a few people, and most of those people say they now use a method like that. Of course, it always comes with a warning not to use
Re: (Score:2)
nice.
Re: (Score:2)
And they will never use words
Re: (Score:3)
They won't even think that way. So the average user won't do that. Period. Full stop.
Well, in my experience, *normal* users do use them (nurses, managers and sales staff included), because if it's explained to them in a sensible manner then they will understand it. I don't use the word algorithm with them, I just used it here as I *hoped* that the average /. user had a clue.
I suppose it comes down to the ability to explain what you want users to do. As my thermodynamics tutor once said - "if you can't explain it, you don't understand it". Sorry, but your inability to teach password security
Re:Am I imagining it? (Score:4, Insightful)
Re: (Score:2)
Solution is to dump cram-md5. There are versions that don't require the plaintext passwords, but even in that case it leaves in place inherent weaknesses.
Obligatory (Score:5, Funny)
Re: (Score:2)
It's pretty sad when (Score:3, Funny)
even xkcd beats Slashdot to a story.
Encrypting passwords is "outdated?" (Score:2)
I don't think that was ever considered an acceptable practice...
Re: (Score:2)
This is exactly what I was about to post. I started learning Unix systems in the mid 90s, while the web was still new. Back then, whether to use shadow passwords was still a question asked at install time. Not, should passwords be hashed, that was already long since the standard, but should the hashes be protected.
So at least as far as web services go, encryption vs hashing was NEVER the right or state of the art choice at the time.
Re: (Score:2)
The thing is, so many of these new people put in charge do not have experience to learn from history. Many of them know nothing about Unix but instead have a certificate in ActiveDirectory. Probably the same people who in school thought that math was too hard and that they'd never need it on the job. So lack of experience, plus lack of education, means that their job is basically pasting together different APIs to create an application.
It's true that this creates lots of job security for people with brai
Re: (Score:2)
No we simply were not talking about that. How would that possibly be relevant to discussions of web services which, unless there is some secret history that goes beyond 1992, (are we counting gopher as "the web" now?) then I stand by my statement: So at least as far as web services go, encryption vs hashing was NEVER the right or state of the art choice at the time.
Re: (Score:2)
Whats wrong with encrypting passwords? Are you just objecting to the specific case where no salt (technically nonce) is used and a single encryption key is used for all accounts?
What if they stored it as such-- :: AES(password, sha1(password+username))
SHA1(Username)
Id be interested to see why thats fundamentally weaker than hashing; it certainly can be more useful (such as when you want to use the password as a key for other data without ever having to pass it over the wire).
Re: (Score:2)
That's a hasing algorithm, not encryption. The difference is:
Hash -> data -> value, where everything is deterministic
Encryption -> key -> data -> coded_data, where exist decryption -> key -> coded_data -> data
Your algorithm has the first signature, not the second. I don't know if it is secure, it is certainly not fit for passwords, but it is a hash.
Re: (Score:2)
Your password encryption method leaks the length of the password.
Dear Adobe (Score:5, Interesting)
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.
Et tu, Adobe? (Score:5, Funny)
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...
Re: (Score:2)
Eh, it's their own fault for writing their encryption in Flash!
To be fair... (Score:2)
Storing only hashed, salted passwords has only been common practice since 1970s Unix.
encryption instead of hashing (Score:2)
When was encryption instead of hashing ever best or right practice? Did someone at Adobe just not understand and everyone else at Adobe accepted that?
Very breakable (Score:3, Interesting)
Re:Very breakable (Score:4, Funny)
Please share with us, this, little, simple stistical analysis method.
Re: (Score:2)
>They used ECB, hence no keystream.
Facepalm.
Jobs was right, Adobe is pathetic (Score:2)
gaping holes in the software for black hats, with all the security of a row of shoeboxes on a busy street for their business secrets. there are no grownups there.
Bad passwords on purpose (Score:5, Interesting)
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.
Re: (Score:2)
There's still unfortunately so many people that reuse passwords. Every new MMORPG that comes out now has a huge wave of "hacked" account where the attacker simply used any one of the big password databases that came from these other leaks, and reaps it. The mass, every time, thinks its the game that got hacked. "Omg i have a super strong password....", yet they reuse it, so its irrelevant.
I used to do it the same way you do, with different levels of passwords. I eventually lost track and just started using
KeePass (Score:2)
I used to do it the same way you do, with different levels of passwords. I eventually lost track and just started using KeyPass and generate unique passwords.
I think you mean KeePass [keepass.info] and I quite agree.
Every new MMORPG that comes out now has a huge wave of "hacked" account
It would be interesting to know which "level" people tend to choose for their MMORPGs (at least of those who have "levels"). On the one hand it's just a game, while on the other it involves a gargantuan investment of time and attention.
Hashing is not better than encryption! (Score:2)
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 pro
1Password (Score:2)
I won't even bother railing about how completely incompetent Adobe is. Especially since they are not unique in this problem.
My solution was to use 1password. Encrypted password store that also generates login credentials for me. It has tools for Windows, Mac, iOS and Android (sorry, no linux), and it has plugins for all the major web browsers. Stores everything in AES256, syncs with dropbox so you can sync your database with multiple machines.
Now I can effortlessly create a long fugly password for every
Encryption *IS* better than hashing (Score:2)
I couldn't disagree more with this so called "best practice".
Hashes can be brute forced as a function of strength of users password (universally very poor) and size of password pool (2.9m..hiccup). The situation gets worse and only goes downhill as technology improves. Selecting the latest and greatest hashing algorithm does nothing to change this basic truth. Nor does amplifying weak passwords by a multiplication factor of redundant rounds do anything much useful to fix a problem in which only exponent
Re: (Score:3)
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.
Re: (Score:3)
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
torrent magnet link (Score:3)
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/ [xkcd.com] , this looks like a fun project for a lonely rainy week-end...
Re: (Score:2)
I call "12345"! Nobody else can use it. it's the password for my luggage, so it's especially convenient for me.
Re: (Score:3)
Re: (Score:2)
thanks for the good laugh. it's been a while since i've actually seen the movie. it's available to rent from amazon online for $3. maybe i'll splurge a bit (i mean, "work offsite")
Re: (Score:3)
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 releas
Re: (Score:2)
While poor practice as if the encryption key can be recovered _everyones_ password is now released
That ONLY follows if they are using the same key for everyone. That does not have to be the case.
Re: (Score:2)
True - I assumed this was implied by the released results of some people saying 'password X has y frequency'.
I am guilty of not checking those results, and had assumed that these were simply using several peoples shared passwords from other dumps, which encrypt to the same result and can be easily picked out as common crypted values.
If this was a per-user password key - a salt in effect - this would not occur.
Re: (Score:2)
DES is broken without brute force (although it's also brute-forceable). It's more resistant to differential cryptanalysis than if the S-boxes had been random, but differential cryptanalysis is still better than brute force against it, and so is linear cryptanalysis.
Re: (Score:2)
when i read http://xkcd.com/1286/ [xkcd.com] apparently password hints were exposed in the clear. not cool not cool...
Not at all safe in this instance (Score:2)
XKCD showed why it's not at all safe in this instance. Here's the table:
email cryptw hint
ac@slash.com 737462 first apostle
dumb@adobe.com 737462 hot neighbor
From the encrypted password, we see that these two users have the same password. Now look at the password hints. What do you suppose is the password they BOTH used?
Re: (Score:2)
Re: (Score:2, Flamebait)
SHA-2 is a family of hashes including SHA-256, SHA-512, etc. you dolt. Additionally: Keystretching is fine, so is key stretching and recording the resultant hashes into a chunk of RAM, then hashing that and continuing the process for your keystretching to make it memory hard. SHA-2 can be every bit as effective as any other option you'd go for. You're clearly an ignorant fuck.
Re: (Score:3)
SHA-2 includes both SHA-256 and SHA-512 [wikipedia.org]. 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.
Re: (Score:3)
SHA-2, aka SHA256 or SHA512.
http://en.wikipedia.org/wiki/SHA-2 [wikipedia.org]
The more you know....
Re: (Score:2)
Right. Any other block cipher, including AES, could have been mis-used in this same way. (The issues were that they encrypted passwords instead of hashing them, and that they used their cipher in ECB mode. The 3DES part smells of legacy but isn't a real issue in its own.)