All 32mil RockYou accounts hacked. Passwords were stored in plaintext. • Hacker News Board

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#51

Post by tptacek » Tue, Dec 15, 2009, 3:12 AM UTC

paulgb wrote: post #45

tptacek wrote: post #16

Earlier quoted context omitted.

The "salt" --- which, so far as I can tell, is a term used almost never in academic crypto research --- defeats one very effective exotic attack: the "rainbow table", where an attacker builds a database of perfect hash :: string correspondances. But too many people forget that before the popular Windows cracking tools were released, passwords were cracked exclusively by tools like JtR, which simply contain highly opt…

I certainly get why a slower hash would curb brute force attacks, but when I'm talking about unique salts, slowing down the hash is not the purpose I have in mind. If you have a table of 32 million hashed passwords with no salt (or they have the same salt and you know what it is), you can try a bunch of combinations, take the resulting hash, and look it up in the hashed password database. If you try the password "foo…

Every time I bring this up, which is often because it is, apparently, all I ever talk about here, people misconstrue what I'm saying as some kind of argument against "salted" hashes.

It is true that not even bothing to randomize your hashes is worse than doing so. But when we're talking about degrees of grave badness, I stop being super interested in the conversation.

If, for reasons passing my understanding, you are attached to the idea of using straight SHA1 to hash passwords, iterate SHA1 1000 times. That takes 2 extra lines of code (the opening and closing of the for loop) and significantly improves your security.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#52

Post by far33d » Tue, Dec 15, 2009, 3:16 AM UTC

mattmaroon wrote: post #44

Wait a sec, something is wrong here. I suspect the title is misleading. RockYou has maybe a couple thousand developers tops using their services. They might have 32 million Facebook customers, but those don't have passwords. They're Facebook app users. Facebook does not permit developers to store private info without special permissions, which I've never seen apps of their ilk ask for. So while this hacker could mayb…

RockYou was a widget company - they probably still have usernames and passwords for myspace users.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#53

Post by DenisM » Tue, Dec 15, 2009, 3:17 AM UTC

tptacek wrote: post #16

paulgb wrote: post #10

Earlier quoted context omitted.

Does using a unique salt for each user help here? Is there a non-obvious reason why that approach is bad?

The "salt" --- which, so far as I can tell, is a term used almost never in academic crypto research --- defeats one very effective exotic attack: the "rainbow table", where an attacker builds a database of perfect hash :: string correspondances. But too many people forget that before the popular Windows cracking tools were released, passwords were cracked exclusively by tools like JtR, which simply contain highly opt…

For those using .NET there is a built-in implementation of PBKDF2, it's called called Rfc2898DeriveBytes:

http://msdn.microsoft.com/en-us/library/system.security.cryp...

I did not find a bcrypt/scrypt implementation in standard .NET and I would be reluctant to use third-party security code I googled up somewhere.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#54

Post by jmillikin » Tue, Dec 15, 2009, 3:17 AM UTC

harpastum wrote: post #49

jmillikin wrote: post #41

Earlier quoted context omitted.

Using these numbers, it would take your computer roughly 12 years to check 32M passwords against that string. That's a long time, but feasible (with additional power), and more specialized systems can bring it within reach. In contrast, assuming a 40-character (20 in config, 20 in database) alphanumeric salt, an attacker would have to perform 704423425546998022968330264616370176 digests per row to check 32M passwords…

I think that the salient detail is this: t = Time.now.to_i 1000000.times {Digest::SHA1.hexdigest("ugh8&eat")} puts (Time.now.to_i - t).to_s =>3 Sure, 120ms is a bit long, but I think it would be beneficial to security to require more than 3µs. Edit: I match my parent's problem with 32M checks taking 12 years with my personal computer taking 132.86 seconds to calculate 32M SHA1s.

There are lots of ideas which are beneficial, but not particularly useful. For example, requiring passwords to be at least 120 characters would (in theory) make passwords more difficult to compromise, but in practice users are just going to type "password" 15 times.

Increasing the digest time prevents an attacker with simultaneous access to the server and database from cracking very weak passwords, but at the cost of tripling or quadrupling how much time each request takes. There are some cases where this could be useful -- for example, running a dissident website in an authoritarian country -- but it's user-hostile to implement it anywhere else.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#55

Post by jmillikin » Tue, Dec 15, 2009, 3:18 AM UTC

bigmac wrote: post #50

jmillikin wrote: post #38

Earlier quoted context omitted.

I said "competent"; the UNIX crypt() and Windows LanMan schemes do not count. If you have any information about defeating a properly implemented salt+hash system, I (and every other developer in the world) would be eager to hear it. For example, I just generated a salt/digest combination for a simple example password. It is digested using SHA-1, and the password is four ASCII digits. Here is the database row -- '|' i…

Does this include a config file salt as well?

The config salt isn't present in my post -- I'm assuming a database breach, like that which usually occurs. The digest does include a config salt, of course -- this isn't the '70s.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#56

Post by ars » Tue, Dec 15, 2009, 3:22 AM UTC

jmillikin wrote: post #38

tptacek wrote: post #23

Earlier quoted context omitted.

That first paragraph is a funny statement, since every Unix security book ever written explains how to use Crack, a tool written before I even got into high school, to rip through Unix salted passwords. I don't think it even bears arguing. The second point is valid but not particularly meaningful. You could also try "12345" and "password" over the network using the login page as an oracle, given a list of usernames.…

I said "competent"; the UNIX crypt() and Windows LanMan schemes do not count. If you have any information about defeating a properly implemented salt+hash system, I (and every other developer in the world) would be eager to hear it. For example, I just generated a salt/digest combination for a simple example password. It is digested using SHA-1, and the password is four ASCII digits. Here is the database row -- '|' i…

It's traditional to also including a testing row, revealing the password (along with the digest), so that people can verify that their cracking code works.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#57

Post by mikebo » Tue, Dec 15, 2009, 3:28 AM UTC

jmillikin wrote: post #47

DarkShikari wrote: post #43

Earlier quoted context omitted.

If the attacker can get the list of password hashes, what's stopping him from getting your salts too? You're basically just splitting the passwords into two components--two-factor security--except that two-factor security requires two separate concepts, not simply requiring two passwords.

Salts are usually stored in two components; one is in the database and unique per row, to prevent cracking multiple rows at once. The other component is in a config file in the server -- it adds a constant number of bytes to the input for any brute force attempt. If an attacker can achieve a root login to your server, then they can read your config file, but they can also just change the login form to email them pass…

If your webserver machines are so secure, why put them in the database at all? Just store the passwords on disk there, rsync the password file across all machines and you're set.

I kid, but I really think you and tptacek just have different standards. tptacek's is higher.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#58

Post by tsally » Tue, Dec 15, 2009, 3:28 AM UTC

epochwolf wrote: post #48

tsally wrote: post #18

Earlier quoted context omitted.

It happened (storing in plaintext, not losing the actual passwords): http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with... We've covered 37signals poor approach to security before: http://news.ycombinator.com/item?id=804257 It's my understanding that they've since reformed. I'd be interested in what books you think they've written that provide credible security advice. Blind "fanboyism" (if I may invent a w…

Both of those links are not proof of any lax security at 37signals. The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) You can read more about that in the comments on that blog. [ignore] The second link is about a security problem in r…

The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption.

Using symmetric encryption to encrypt passwords in a database would not be smart. Where are you going to keep the key? If the hacker gets the dbase, then they've probably got the key as well.

There's no point in dancing around this issue. The only acceptable way to store passwords is a slow one way hash. If you get your password in plaintext, the security is lax.

The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time.

The bad part about the second link isn't that the vulnerability happened, its that 37signals had no infrastructure in place for security researchers to report problems. Of course vulnerabilities are going to happen. It's a certainty. But you need to have a system in place for the good guys to report problems. I'm not aware of any informed person that criticized them for the actual vulnerability. If you read the link I provided, you'll notice this quote:

"It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them."

They've got a communication channel now: http://37signals.com/security-response.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#59

Post by harpastum » Tue, Dec 15, 2009, 3:28 AM UTC

anigbrowl wrote: post #6

given the nature of their service, I can't help suspecting the bulk of their clientele use one password for everything. Awesome.

I agree with you, in that you're saying it's silly for RockYou to assume their customer's passwords are unique to their service, but I vehemently disagree with your unstated assumption--that 99.99% of other communities aren't just as likely to have users pick dumb passwords.

I don't mean this to come off as ad hominem, because I don't think it was your intention to leave the opposite side of the argument open and I think you personally understand the issue. I just think that we shouldn't have a mentality of "aww, we need to take special care of these unsavvy users." Not having basic levels of security in place for any user-base is simply unacceptable.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#60

Post by tptacek » Tue, Dec 15, 2009, 3:28 AM UTC

jmillikin wrote: post #38

tptacek wrote: post #23

Earlier quoted context omitted.

That first paragraph is a funny statement, since every Unix security book ever written explains how to use Crack, a tool written before I even got into high school, to rip through Unix salted passwords. I don't think it even bears arguing. The second point is valid but not particularly meaningful. You could also try "12345" and "password" over the network using the login page as an oracle, given a list of usernames.…

I said "competent"; the UNIX crypt() and Windows LanMan schemes do not count. If you have any information about defeating a properly implemented salt+hash system, I (and every other developer in the world) would be eager to hear it. For example, I just generated a salt/digest combination for a simple example password. It is digested using SHA-1, and the password is four ASCII digits. Here is the database row -- '|' i…

[Updated: You're not using SHA1, you're using keyed SHA1 with a secret random key. Presumably it's long, because you made your per-password salt ludicrously long, because you don't really understand how salts work. Note that every "read any file the web app can" vulnerability on your system is now "recover tens of thousands of passwords". It would be extra funny if you hashed your config file salt second instead of first, but I'll leave it up to the experts on your team to figure out why that is.].

It takes 5us on this system to do one SHA1 calculation. You're not using ASCII "digits" (if you were, I'd know, because brute forcing all the 4-digit numeric strings took less than a second); you meant characters. There are ~130MM 4-digit character combinations in standard ASCII.

Maybe I'm misunderstanding something about this challenge, but, if I'm not, post the code you used to generate this comment so I don't waste my time attacking a salt that is secretly Base64'd, and in 10 hours, you can mail your check to Amnesty International.