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

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

techcrunch.com

Post reply on HN
Print view View original

41–50 of 112 posts

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

#41

Post by jmillikin »

tptacek wrote: post #32
jmillikin wrote: post #29

Earlier quoted context omitted.

"salting" also prevents brute-forcing. Assuming a bare-basics implementation (20-char salt in config file, 20-char salt per user, prepended to the password), the only way an attacker can brute-force passwords in a reasonable timeframe is to compromise the server itself. At that point, it would be just as easy to make the login form mail him passwords. Merely choosing a slower digest doessn't help, because the digest…

If you can't understand the significance of these two results (and this is with the default cost factor for BCrypt), you're just arguing to hear yourself talk. t1 = Time.now.to_i 100.times { BCrypt::Password.create("ugh8&eat") } puts Time.now.to_i - t1 => 12 t1 = Time.now.to_i 100.times { Digest::SHA1.hexdigest("ugh8&eat") } puts Time.now.to_i - t1 => 0 I could raise the number of iterations to bring SHA1 above the m…

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.

Unless you believe that is an insufficient barrier, implementing BCrypt is merely degrading the user experience (12-second logins? come on) for no real improvement.

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

#42

Post by rpbertp13 »

tptacek wrote: post #32
jmillikin wrote: post #29

Earlier quoted context omitted.

"salting" also prevents brute-forcing. Assuming a bare-basics implementation (20-char salt in config file, 20-char salt per user, prepended to the password), the only way an attacker can brute-force passwords in a reasonable timeframe is to compromise the server itself. At that point, it would be just as easy to make the login form mail him passwords. Merely choosing a slower digest doessn't help, because the digest…

If you can't understand the significance of these two results (and this is with the default cost factor for BCrypt), you're just arguing to hear yourself talk. t1 = Time.now.to_i 100.times { BCrypt::Password.create("ugh8&eat") } puts Time.now.to_i - t1 => 12 t1 = Time.now.to_i 100.times { Digest::SHA1.hexdigest("ugh8&eat") } puts Time.now.to_i - t1 => 0 I could raise the number of iterations to bring SHA1 above the m…

His computer is taking 12 seconds for 100 iterations. The time spent checking the password would be more like 120 ms, totally in the order of a decently fast http request.

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

#43

Post by DarkShikari »

jmillikin wrote: post #29
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…

"salting" also prevents brute-forcing. Assuming a bare-basics implementation (20-char salt in config file, 20-char salt per user, prepended to the password), the only way an attacker can brute-force passwords in a reasonable timeframe is to compromise the server itself. At that point, it would be just as easy to make the login form mail him passwords. Merely choosing a slower digest doessn't help, because the digest…

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.

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

#44

Post by mattmaroon »

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 maybe see what digital birthday card was sent to whom, that's probably about the extent of the damage.

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

#45

Post by paulgb »

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…

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 "foobar" and any user has the password "foobar", you've found a username/password pair. Because there are 32 million potential matches, your chances are pretty good of eventually finding a bunch of matches by iterating over a bunch of potential passwords.

On the other hand, if you have a table of 32 million hashed passwords and salt combinations, where the salts are unique, you have to check the hash of "foobar" in combination with every user's salt before you can say that no user has the password "foobar". This is 32 million times slower, which is a significant difference regardless of the speed of the hashing algorithm.

If you want to brute force a particular user's password, the unique hash doesn't matter, but if you want to maximize the number of username/password pairs you can get, it seems to me like it would.

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

#46

Post by [deleted] »

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…

[deleted]

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

#47

Post by jmillikin »

DarkShikari wrote: post #43
jmillikin wrote: post #29

Earlier quoted context omitted.

"salting" also prevents brute-forcing. Assuming a bare-basics implementation (20-char salt in config file, 20-char salt per user, prepended to the password), the only way an attacker can brute-force passwords in a reasonable timeframe is to compromise the server itself. At that point, it would be just as easy to make the login form mail him passwords. Merely choosing a slower digest doessn't help, because the digest…

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 passwords. For this reason, most password defense is aimed at the assumption that the attacker gained access to the database server, but not the webserver. Historically, this has proven to be a safe assumption.

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

#48

Post by epochwolf »

tsally wrote: post #18
tree5 wrote: post #12

Earlier quoted context omitted.

I doubt that. They're led by probably the strongest Rails team anywhere, and they (DHH + team) wrote books on avoiding what RockYou just did. EDIT: I'm specifically referring to DHH's "Agile Web Development With Rails", Chapter 11, Administration

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

Okay, issue was with the lack of a secure channel. Point taken. That was a mistake.

[Removed section on procedures and mistakes, as non-relavent.]

(Disclosure: I use ruby on rails)

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

#49

Post by harpastum »

jmillikin wrote: post #41
tptacek wrote: post #32

Earlier quoted context omitted.

If you can't understand the significance of these two results (and this is with the default cost factor for BCrypt), you're just arguing to hear yourself talk. t1 = Time.now.to_i 100.times { BCrypt::Password.create("ugh8&eat") } puts Time.now.to_i - t1 => 12 t1 = Time.now.to_i 100.times { Digest::SHA1.hexdigest("ugh8&eat") } puts Time.now.to_i - t1 => 0 I could raise the number of iterations to bring SHA1 above the m…

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.

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

#50

Post by bigmac »

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…

Does this include a config file salt as well?
Post reply on HN