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

91–100 of 112 posts

Re: Adobe confirms stolen passwords were encrypted, not hashed

#91

Post by alexwright »

bennyg wrote: post #89
annnnd wrote: post #87

Earlier quoted context omitted.

What is that all about? The site makes a claim of making a search through 150mio records a big deal. Ok, it is not trivial, but any decent DB with proper indexes would have no trouble doing that. Am I missing something? Also, they want me to enter my e/mail to check... . Seriously?

It checks if your email is in the dump. What would you want, just a full list of everyone's emails in plaintext for the world to see?

A form to enter the sha1 of your email address so they can check against a list of addresses they've already sha1ed? And a form that takes the email for people that don't give a shit or don't know wtf a sha is.

Maybe just a .txt of the hashes too, but then no ones coming to your web service I guess.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#92

Post by josefresco »

nudetayne wrote: post #36

Anytime I register anywhere, I do the following: 1. Use a new or willing-to-be-spammed email address. 2. Use a new phrase-based password. I write all of this information down on pieces of paper that I keep at my desk. I have a lot of scribbled up paper at this point.

Lock your office doors!

Re: Adobe confirms stolen passwords were encrypted, not hashed

#93

Post by 0x0 »

bigiain wrote: post #46
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 soun…

Oh you mean like having the code signing service being compromised and used to signed malware?

http://www.zdnet.com/adobe-code-signing-infrastructure-hacke...

Re: Adobe confirms stolen passwords were encrypted, not hashed

#94

Post by 0x0 »

tedunangst wrote: post #39
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…

Roughly, yes. You can't just run through the database and crack every account that used one of the top 1000 passwords (password, secret, sex, ...). But since you can see all the accounts that have the same password, that lets you: 1. identify all the people who used a popular password 2. identify anyone who happened to use the same password as one you already know, such as your own. 1 + 2 = 3. if you mount an online…

And when someone else happened to use the same password as you, and enter an obvious "password hint" - too bad for the others who tried to be cautious with their password hints...

Re: Adobe confirms stolen passwords were encrypted, not hashed

#95

Post by borplk »

Nowadays that everyone has lots of accounts and there are so many good password managers around I don't know why losing passwords is so important.

I couldn't care less if Adobe stored my password in plaintext. It's unique to that service and used absolutely nowhere else and I don't even have to remember it.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#96

Post by jbtule »

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…

But how do you keep the key from getting stolen, when you couldn't keep the password database from being stolen?

Re: Adobe confirms stolen passwords were encrypted, not hashed

#97

Post by happimess »

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…

For anyone wondering about the acronyms above, ECB is Electronic Codebook, CBC is Cipher-block Chaining, and IV is an Initialization Vector used in CBC. IND-CPA is Indistinguishability under chosen-plaintext, a method of attack.

These are explained at [1] and [2]

[1] http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

[2] http://en.wikipedia.org/wiki/Ciphertext_indistinguishability

Post reply on HN