Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Adobe confirms stolen passwords were encrypted, not hashed

csoonline.com

Post reply on HN
Print view View original

41–50 of 112 posts

Re: Adobe confirms stolen passwords were encrypted, not hashed

#41

Post by bigiain »

kevinpet wrote: post #30
tedunangst wrote: post #20

Earlier quoted context omitted.

I'm curious to hear when exactly people think bcrypt became accepted best practice? And how much of a grace period did people have to switch? Were you incompetently negligent if you didn't use bcrypt by 2003? 2007? 2011? (I ask this as a fairly big fan of bcrypt myself. Somehow I just have the impression that half the peanut gallery comments come from people who literally switched over from md5 hashes yesterday and s…

The issue is not bcrypt vs. some other hash. The issue is hashing vs. reversible encryption. Unix has been using salted hashed passwords since the 70s. "one-way hash function" is a common phrase in the first edition of Applied Cryptography published in 1994. http://books.google.com/books?q=isbn:0471597562

Actually, here on HN, "Use bcrypt" has been the war-cry whenever password storage is discussed for quite some time - mostly linking to Coda Hale's blog post from 2010: http://codahale.com/how-to-safely-store-a-password/

(the discussions usually then fragment into the "No, use scrypt instead! GPUs! HashCat! ASICs! Memory-hard vs iterations-hard!" thread, and the "but what if I use an application salt with my MD5 hashes? Or invent my own complification techniques (and keep using MD5)?")

Re: Adobe confirms stolen passwords were encrypted, not hashed

#42

Post by J0415 »

tedunangst wrote: post #20
001sky wrote: post #4

Adobe says that they've followed best practices for password storage and protection for more than a year now... 13 generations of photoshop ...and they're just getting around to this after CS6?

I'm curious to hear when exactly people think bcrypt became accepted best practice? And how much of a grace period did people have to switch? Were you incompetently negligent if you didn't use bcrypt by 2003? 2007? 2011? (I ask this as a fairly big fan of bcrypt myself. Somehow I just have the impression that half the peanut gallery comments come from people who literally switched over from md5 hashes yesterday and s…

Since this http://codahale.com/how-to-safely-store-a-password/

Re: Adobe confirms stolen passwords were encrypted, not hashed

#43

Post by neya »

I don't know about the passwords, but my card was successfully stolen[1] and a malicious transaction was initiated from another country. I know this was because of Adobe for sure because I (co-incidentally) used a brand new, fresh, unique e-mail address just for Adobe, and that email was released recently in the dump that the hackers provided.

Luckily the malicious transaction was declined by my bank and they blocked the card for me and they told me that someone had compromised my card details and issued me with a replacement card free of charge.

I only keep posting this in every thread[1][2] about Adobe because I genuinely want other Adobe customers to understand the gravity of the situation and disable their compromised credit card and get it replaced by a new one as soon as possible.

[1]https://news.ycombinator.com/item?id=6668013 [2]https://news.ycombinator.com/item?id=6632385

Re: Adobe confirms stolen passwords were encrypted, not hashed

#44

Post by yeukhon »

kevinxucs wrote: post #32

What's worse, see http://xkcd.com/1286/ They use a technique similar to ECB, which results in completely linear cipher text blocks.

The xkcd references comic 792 and I totally agree that at any given time there is a website people going to sign up and they will never realize the author of the website stores everything in plaintext so he could get your username and password. This is why we need to push identity services like Persona.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#45

Post by ReidZB »

jordanthoms wrote: post #37

To play devil's advocate here, isn't this actually more secure than something like MD5 or SHA1 without stretch factors or multiple invocations, assuming that the key was not also stolen? My reasoning is, that in order for an attacker to get the passwords out of this dump, they have to break the 3DES encryption. Brute forcing the key is, as I understand it, still very difficult, and without it they can't get any of th…

You're right --- had they used something other than ECB mode. For example, if they used CBC mode with a proper IV, assuming the key is not stolen or compromised, the passwords would be quite secure.

The issue becomes verifying the passwords, then: supposing you have a CBC mode oracle, like a HSM, how can you verify two passwords are the same? (This is probably the reason they chose ECB mode in the first place.) In fact, if you allow the user to test if two ciphertexts represent the same plaintext --- and nothing else --- you still break the very definition of secure encryption, namely that a secure encryption scheme should have, as one popular definition, indistinguishable ciphertexts (usually under a chosen-plaintext attack).

So you have to develop some new way to measure security for the scheme, or perhaps somehow measure the damage that an equality oracle can inflict upon an IND-CPA secure scheme. The notion of indistinguishable ciphertexts roughly reflects the inability of an attacker to reliably learn any function of the plaintext from the ciphertext. Throwing that idea out the window seems unwise, since it's such an elegant idea. So, anyway, you're off in uncharted waters, not a good place to be if you're securing users' passwords.

All of that is relatively complex, though, so just let me know if I need to elaborate on some idea more. (I am never sure how in-depth to go in these posts.)

Re: Adobe confirms stolen passwords were encrypted, not hashed

#46

Post by bigiain »

jordanthoms wrote: post #37

To play devil's advocate here, isn't this actually more secure than something like MD5 or SHA1 without stretch factors or multiple invocations, assuming that the key was not also stolen? My reasoning is, that in order for an attacker to get the passwords out of this dump, they have to break the 3DES encryption. Brute forcing the key is, as I understand it, still very difficult, and without it they can't get any of th…

" … assuming that the key was not also stolen?"

Is that a sensible/defensible assumption though?

from: http://www.csoonline.com/article/742228/stolen-adobe-account...

"In an update on the data breach disclosed earlier this month, Adobe has said that source code for Photoshop was stolen."

I might be being overly paranoid, but I've shut down Adobe's Air/Acrobat/Flash updaters at the firewall until I hear plausible sounding assurances that Adobe didn't lose _everything_ in this breach, including software signing keys, update servers, DNS SOAs – the whole lot. _Maybe_ some of that stuff was better secured than the Photoshop source code… But would you bet every machine on your network that they "only" lost ~130million account credentials and the Photoshop source code, but nothing else?

Re: Adobe confirms stolen passwords were encrypted, not hashed

#48

Post by bigiain »

J0415 wrote: post #42
tedunangst wrote: post #20

Earlier quoted context omitted.

I'm curious to hear when exactly people think bcrypt became accepted best practice? And how much of a grace period did people have to switch? Were you incompetently negligent if you didn't use bcrypt by 2003? 2007? 2011? (I ask this as a fairly big fan of bcrypt myself. Somehow I just have the impression that half the peanut gallery comments come from people who literally switched over from md5 hashes yesterday and s…

Since this http://codahale.com/how-to-safely-store-a-password/

While Coda's 2010 blog post is clearly the most commonly linked-to bcrypt reference – the post itself includes a many links including one to an article by Derek Slager (quoting tptacek) from 2007, links t both Java and Perl implementations from 2006, and a link to a Usenix paper from 1999.

If Adobe didn't switch to intentionally-slow hashes with proper salting until "last year", that puts them over 20 years behind "best practice" (as well as 2 or 3 years behind fully deserving of online mockery, laughable uninformed-newbie levels of security engineering).

Re: Adobe confirms stolen passwords were encrypted, not hashed

#49

Post by hamburglar »

dorian-graph wrote: post #15
mayneack wrote: post #14

Anyone got a link to where one might check for the presence of their own email in this list?

http://adobe.cynic.al/

Is there a better way than typing my email address into a site of questionable integrity?

Re: Adobe confirms stolen passwords were encrypted, not hashed

#50

Post by yeukhon »

ReidZB wrote: post #45
jordanthoms wrote: post #37

To play devil's advocate here, isn't this actually more secure than something like MD5 or SHA1 without stretch factors or multiple invocations, assuming that the key was not also stolen? My reasoning is, that in order for an attacker to get the passwords out of this dump, they have to break the 3DES encryption. Brute forcing the key is, as I understand it, still very difficult, and without it they can't get any of th…

You're right --- had they used something other than ECB mode. For example, if they used CBC mode with a proper IV, assuming the key is not stolen or compromised , the passwords would be quite secure. The issue becomes verifying the passwords, then: supposing you have a CBC mode oracle, like a HSM, how can you verify two passwords are the same? (This is probably the reason they chose ECB mode in the first place.) In f…

> The issue becomes verifying the passwords, then: supposing you have a CBC mode oracle, like a HSM, how can you verify two passwords are the same? (This is probably the reason they chose ECB mode in the first place.)

Why is that? What's wrong with verifying a password in CBC mode with different IV?

Post reply on HN