Live data from Hacker News

Adobe confirms stolen passwords were encrypted, not hashed

csoonline.com

61–70 of 112 posts

Re: Adobe confirms stolen passwords were encrypted, not hashed

#61
As a small aside about Adobe security practices, I needed customer support from them the other year (its own horror story). As part of this, customer support insisted on setting up an Adobe account, although I'd purchased the product through a third party vendor and not directly from Adobe (as it turns out, thank goodness!).

When looking up that account information, I saw the note I made as to the original password they gave that account that they set up: "123456". I had changed it away from that; I suspect a significant number of their users might not have.

Glad that account contained only a name and ZIP code / town.

AND the serial number. If someone consumed a spare slot on the serial number, I shudder to think of how many hours on the phone with Adobe support it might take to get that slot freed up.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#62

So, if Adobe engineers eventually realized that they needed to upgrade their password security, and they had access to the passwords in their DB (they used 3DES, and they had the key) - why did they not immediately decrypt and hash all passwords?

It sounds like they did do that, and this system was the old database which was no longer in use, but they didn't shut it down.

See neya's comment here, who believes his credit card was taken from there amd he claims to have recently purchase something.

My theory is Adobe didn't use SHA2 even recently, it's probably something that they only started to develop.

And SHA2 is still wrong, BTW. See other comments here.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#63
post #22

Earlier quoted context omitted.

http://adobe.cynic.al/

Is it ironic that to check if my email is vulnerable i'm typing it in to a website that i'm not sure whether to trust?

My thought exactly... I did not choose to do so =P

Re: Adobe confirms stolen passwords were encrypted, not hashed

#64
post #50
post #45

Earlier quoted context omitted.

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?

I am assuming that the DB server cannot decrypt. If the DB server has decryption permissions, and it is compromised, then there's little need in encrypting the passwords anyway as an attacker will simply decrypt them by hand. (They may not get all of them before being detected, but they'd still get some or most --- and they might look for high-value targets!)

Unlike ECB mode, you can't just encrypt the same password again and check to see if the ciphertexts are the same --- the IVs will be different (hopefully!). So, can you somehow check two ciphertexts with different IVs to see if they represent the same plaintext? Nope, probably not: if you could, then the scheme would no longer have indistinguishable encryptions under a chosen-plaintext attack [1]. Briefly, this ability to test if two ciphertexts represent the same plaintext would allow the adversary in the IND-CPA game to simply encrypt both of the plaintexts and test them against the challenge ciphertext. (See the [1] reference for more info on this.)

In fact, this is exactly the property you don't want. You don't want to be able to determine if two users have the same password. If the DB server were able to test ciphertext equality, then it could pairwise-test each pair of users (or again only hunt for high-value targets).

If you were really adamant on encrypting passwords, I'd also suggest that we'd need to pad the password out to the max password length to prevent the revelation of password length. But of course, I very strongly suggest against password encryption. Still: that's another thing to consider in this hypothetical scenario.

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

Re: Adobe confirms stolen passwords were encrypted, not hashed

#65
post #23

Earlier quoted context omitted.

If Photoshop, basically industry standard in image-editing software, isn't an achievement... then nothing qualifies as an achievement. And this is coming from someone who prefers GIMP on linux. I would love to produce something even a quarter as popular & usable as Photoshop.

It might be more of a reflection on my colleagues and I, but the phrase "industry standard" is basically used to mean something is crap by us. This is in radiology. UI inconsistency, buggy, crashy (as in 40 minutes to reboot the damn system), incompatibility with other systems etc. When you complain, you're told its industry standard, or similar. And this is just one system I use. There are other standards too. The c…

If PS (or other system) makes your machine need a reboot, the problem isn't Photoshop

The reason Photoshop consolidated itself: first mover advantage. Everybody else is playing catch

Now, in the "the company is paying" field, yes, standards are rock-bottom, or even lower. But I don't think PS gets so low.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#66

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…

There's an essential note which is not quite clear from the article too: while encryption algorithms are reversible, most hashes are not -- sometimes we forget, but they're soft of by definition many-to-one (injective) functions -- while encryption is fully reversible (albeit mathematically "hard"). Of course, this won't matter for websites that use the same hashing algorithm, but it's an essential part of why it doe…

Yeah, secure hashes are (hopefully) not mathematically reversible - but when you can try 350 billion combinations per second on a GPU cracking setup, that stops being such a great defense. This is why you have to use a slow hashing function.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#67

Earlier quoted context omitted.

It might be more of a reflection on my colleagues and I, but the phrase "industry standard" is basically used to mean something is crap by us. This is in radiology. UI inconsistency, buggy, crashy (as in 40 minutes to reboot the damn system), incompatibility with other systems etc. When you complain, you're told its industry standard, or similar. And this is just one system I use. There are other standards too. The c…

If PS (or other system) makes your machine need a reboot, the problem isn't Photoshop The reason Photoshop consolidated itself: first mover advantage. Everybody else is playing catch Now, in the "the company is paying" field, yes, standards are rock-bottom, or even lower. But I don't think PS gets so low.

"If PS (or other system) makes your machine need a reboot, the problem isn't Photoshop" The system is provided, hardware, and all, by the manufacturer. The problem is both hardware and software. Flagship model too. GE.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#68

Earlier quoted context omitted.

If PS (or other system) makes your machine need a reboot, the problem isn't Photoshop The reason Photoshop consolidated itself: first mover advantage. Everybody else is playing catch Now, in the "the company is paying" field, yes, standards are rock-bottom, or even lower. But I don't think PS gets so low.

"If PS (or other system) makes your machine need a reboot, the problem isn't Photoshop" The system is provided, hardware, and all, by the manufacturer. The problem is both hardware and software. Flagship model too. GE.

Ah ok, I should have imagined.

HW companies do not know how to do SW.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#69
post #43

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…

Is there an online service to check your email address is in there? I didn't get an email from them (perhaps it got stuck in my spam folder that gets auto-deleted weekly), but my credit card got hacked soon after.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#70

Earlier quoted context omitted.

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

Worth noting that Gawker got shat on precisely for using unix salted passwords, so what you're saying isn't the issue is at least some of the issue.

[deleted]
Post reply on HN