Become a fan of Slashdot on Facebook


Forgot your password?
Encryption Security

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."
This discussion has been archived. No new comments can be posted.

Stolen Adobe Passwords Were Encrypted, Not Hashed

Comments Filter:
  • Am I imagining it? (Score:5, Insightful)

    by cpicon92 ( 1157705 ) <> on Tuesday November 05, 2013 @01:28PM (#45337053)

    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...

    • by AmiMoJo ( 196126 ) *

      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.

      • 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?"

        • Personally, I would never allow sensitive user data to be used in a Dev environment in the first place. You shouldn't need to, and it creates an additional potential target for attackers.
      • 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.

    • by vadim_t ( 324782 )

      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.

      • by TheNastyInThePasty ( 2382648 ) on Tuesday November 05, 2013 @02:16PM (#45337593)

        Hashing + Salting = Problem Solved.

        • by vadim_t ( 324782 ) on Tuesday November 05, 2013 @02:28PM (#45337709) Homepage

          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.

          • 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.

          • by blueg3 ( 192743 ) on Tuesday November 05, 2013 @03:47PM (#45338605)

            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.

        • 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

        • >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.

      • by ron_ivi ( 607351 )

        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 (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

        • by Pope ( 17780 )

          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.

    • I'm guessing selection bias - entities with the security knowledge to use proper authentication techniques probably are also better at keeping their internal databases out of malicious hands. (Or, more negatively, the contraposition of that statement.) On a related note, this breach has caused me to update all of my own passwords, and my current pet peeve are entities that have an upper limit to password length within the current range of rainbow-table attacks (and what are the chances those guys are proper
      • ... 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.

    • Because if Adobe had no way of decrypting the passwords, they wouldn't be able to provide them to the NSA.

    • Because when a company follows best security practices it does not have its data breached in the first place.

    • 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".)

    • by Charliemopps ( 1157495 ) on Tuesday November 05, 2013 @02:22PM (#45337653)

      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?"

      • Because it really doesn't matter much. You will never find one victim of this Adobe hack who would rather have been in a fender bender.
    • 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?

      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

      • 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

    • 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

      • I use bcrypt - but then again you can pretty much f*ck it up using a work cost which isn't reasonable these days...
      • 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.

    • by tepples ( 727027 )

      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.

      • 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

    • 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)

    • 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

  • Obligatory (Score:5, Funny)

    by stewsters ( 1406737 ) on Tuesday November 05, 2013 @01:29PM (#45337065)
  • I don't think that was ever considered an acceptable practice...

    • by TheCarp ( 96830 )

      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.

      • 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

    • 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--
      SHA1(Username) :: AES(password, sha1(password+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).

      • 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.

      • Your password encryption method leaks the length of the password.

  • Dear Adobe (Score:5, Interesting)

    by Picass0 ( 147474 ) on Tuesday November 05, 2013 @01:37PM (#45337165) Homepage Journal

    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.

  • by CCarrot ( 1562079 ) on Tuesday November 05, 2013 @01:44PM (#45337235)

    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...

  • Storing only hashed, salted passwords has only been common practice since 1970s Unix.

  • 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)

    by shellster_dude ( 1261444 ) on Tuesday November 05, 2013 @02:25PM (#45337671)
    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.
  • 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.

  • by GlobalEcho ( 26240 ) on Tuesday November 05, 2013 @03:02PM (#45338141)

    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.

    • by Shados ( 741919 )

      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

      • 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 [] 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.

  • 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

  • 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

  • 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

    • 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.

  • by rduke15 ( 721841 ) <rduke15&gmail,com> on Tuesday November 05, 2013 @05:56PM (#45340101)

    Here is the essential part missing from the summary:


    The file is called users.atr.gz, and is 4 GB.

    As already shown by [] , this looks like a fun project for a lonely rainy week-end...

Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"