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

71–80 of 112 posts

Re: Adobe confirms stolen passwords were encrypted, not hashed

#71

Post by po »

wesley wrote: post #69
neya wrote: 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.

This one: http://adobe.cynic.al/

Re: Adobe confirms stolen passwords were encrypted, not hashed

#72

Post by ddebernardy »

bigiain wrote: post #48
J0415 wrote: post #42

Earlier quoted context omitted.

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 "b…

The article also states they switched to sha-256. Best I'm aware, that algorithm isn't adaptive, so they may have just as well used md5.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#73

Post by alexkus »

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…

So do multiple things to make it harder for the naughty people, i.e. hash and then encrypt the result.

Hashing or Encrypting?

1) If you have to choose one or the other then obviously hashing (with a random salt and a relatively expensive algorithm, e.g. bcrypt et al with suitable work factor) is generally the way to go.

But it is still possible to brute force many of the easy passwords from a DB leak of bcrypt() hashes, it just takes a bit of time. From there you get to know that email address X uses password Y, which may open the door for hacking into other accounts where they've used the same passwords.

The people that get fucked over first from a DB leak of hashed passwords are those with weak passwords. A poor hashing algorithm (unsalted MD5, etc) may even expose seemingly "unguessable/random" passwords thanks to rainbow tables.

Even with bcrypt() hashed passwords you should be able to work through a huge portion of the top 100 passwords for all 130M accounts and come out with a huge number of email/password pairs.

Increasing the work factor of the hashing algorithm is a trade off, too high and you'll soon need extra servers just to cope with the extra CPU load of people logging in and having to check their passwords, too low and the hashes are easier to crack.

2) But, why not use bcrypt() to hash the passwords, and then some encryption algorithm to encrypt the resulting hashes?

Before anyone jumps in with it, doing this is not "security by obscurity" because you're not relying on the encryption key remaining secret alone to protect the password.

What it does protect you from is a basic leak/dump of the DB being open access for those who want to try cracking the bcrypt() hashes.

They're left with an initial problem of finding the encryption key before they can even start on the bcrypt() dictionary attack.

Sure it just takes someone to grab a copy of the login code (or wherever the encryption key is being stored) but you've protected yourself from a basic SQL injection attack that could be used to just dump the DB without access to the server to compromise the login code.

Also, hints:-

Why weren't the hints encrypted? (Including having a random n character 'salt' that is prefixed to them before encryption to prevent the same hints encrypting to the same string).

If the hints were encrypted you couldn't use them to help guess passwords.

Even if the passwords were hashed rather than encrypted, the unencrypted treasure trove of password hints would make the job of cracking the passwords much much easier.

Why were the hints even stored in the same table (or even on the same server) as the passwords? (Maybe they weren't and the hackers got both and combined the two datastores.)

Again, if the server was compromised enough that the source for the login code was obtained then the hints would effectively be in plaintext, but you've still protected the hint data from a simple DB dump hack.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#74

Post by antocv »

ReidZB wrote: post #64
yeukhon wrote: post #50

Earlier quoted context omitted.

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

Why go through all that when you could use the username or email together with the password to encrypt it with 3DES ECB mode? Those would be unique and users who have same passwords would still have different ciphertexts.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#76

Post by StavrosK »

alexkus wrote: post #73
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…

So do multiple things to make it harder for the naughty people, i.e. hash and then encrypt the result. Hashing or Encrypting? 1) If you have to choose one or the other then obviously hashing (with a random salt and a relatively expensive algorithm, e.g. bcrypt et al with suitable work factor) is generally the way to go. But it is still possible to brute force many of the easy passwords from a DB leak of bcrypt() hash…

I'm sorry, how can you check easy passwords with bcrypt? Hell, checking just one password per account, assuming bcrypt takes around half a second (what most reasonable implementations take) would take two years. If you want to check the 100 most common passwords for everyone, that's 200 years right there.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#79

Post by speeder »

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…

Some people are claiming credit cards used to buy CS6 and whatnot are compromised too.

Re: Adobe confirms stolen passwords were encrypted, not hashed

#80

Post by alexkus »

StavrosK wrote: post #76
alexkus wrote: post #73

Earlier quoted context omitted.

So do multiple things to make it harder for the naughty people, i.e. hash and then encrypt the result. Hashing or Encrypting? 1) If you have to choose one or the other then obviously hashing (with a random salt and a relatively expensive algorithm, e.g. bcrypt et al with suitable work factor) is generally the way to go. But it is still possible to brute force many of the easy passwords from a DB leak of bcrypt() hash…

I'm sorry, how can you check easy passwords with bcrypt? Hell, checking just one password per account, assuming bcrypt takes around half a second (what most reasonable implementations take) would take two years. If you want to check the 100 most common passwords for everyone, that's 200 years right there.

Sure, someone on a single machine isn't going to get far, but that's not a great defence to rely upon.

The answer is one of two things:-

Botnets, which most hacking groups will have some access to. Being in control of a modest 10,000 machine botnet reduces that 200 years to about a week, call it 5 weeks if you limit utilisation to 20% of a single core. Expect more of this when bitcoin mining on botnets becomes less profitable.

Also, despite bcrypt() being designed not to be easy/fast to implement on GPUs because of the memory footprint required, GPUs are growing in size and reasonable implementations exist for FPGAs. ASICs would be even faster.

Upping the work factor to compensate for this makes more work for the CPUs at the site that is using bcrypt(). I know of one company that has more cores utilised in performing bcrypt() checks than they do running the HTTP and DB portions of the site.

Post reply on HN