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

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

#71

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

bootload wrote: post #69

jasonlbaptiste wrote: post #7

This is just some amateur hour shit. They're a well established and well funded company. How do venture funds not do better technical due diligence(or any at all)? I wouldn't release an app for 32 of my friends to test, let alone 32 million people to use with plain text passwords. Enough of my bitching, because it's inaction. Now for words of action/openings for suggestion: How do we make sure companies don't do dumb…

"... How do venture funds not do better technical due diligence(or any at all)? ... How do we make sure companies don't do dumb things like this? ..." Because it's not seen by "management" or "VC's" as a priority. Extra programming is seen as a time and monetary cost, not a necessity. One company I worked for used plain-text for customer passwords and mandated Microsoft technology in the same breath. When I talked to…

The few times I've been through VC and acquirer due diligence, the actual technical depth to it was extremely minimal. They aren't validating your design; they're just determining whether you can actually build working stuff.

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

#72

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

tptacek wrote: post #60

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…

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

> You're not using SHA1, you're using keyed SHA1 with a secret random key.

Does that mean that doing so is OK, except for the read any file breach?

Because I've been doing that cookie authentications. Database and file reads are not something I'm worried about (for this situation), but I don't want the cookie to be easy to crack.

I.e. auth = sha1('long secret string' . 'user_id' . 'password') /* I include the password to invalidate existing cookies if someone changes their password */

I then set a cookie to the user_id, and another cookie to auth, and check them on every page.

Also, I'm not him, so I'd like to know why doing the config salt second instead of first is bad. I thought you could do a partial hash, i.e. hash the config salt once, then just keep updating it with the rest. Meaning, the config salt should go second, not first.

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

#73

Post by makulit » Tue, Dec 15, 2009, 3:52 AM UTC

tptacek wrote: post #60

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…

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

Jmilikin already stated the config salt is not present, that the password IS 4 ASCII digits and he assumes a database breach.

Isn't it up to the attacker to figure out the rest of the details? As an attacker, do you think he has a separate config salt in a file or a separate table or secondary system? That's why you DO spend 10 hours on attacking it if you want the results. His posting seems quite legitimite to me.

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

#74

Post by epochwolf » Tue, Dec 15, 2009, 3:52 AM UTC

Nwallins wrote: post #63

epochwolf wrote: post #48

Earlier quoted context omitted.

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…

There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) So, is there any less sensitivity (security-wise) regarding the key, instead of the password?

It's more common to get access to the database through sql-injection rather than hacking the server. So having the encryption key on disk is more secure than plain text in a database but not much more.

It's also possible for the encrypted passwords to be stored in a separate server that only provides a simple web service with two operations: update_password(email, password), mail_password(email) and store passwords hashed in the main database for authentication.

That said, it is far more dangerous to store passwords in a reversible manner than in an irreversible one. I was just noting it was possible to have modestly secure two-way storage.

Personally, I don't even want to deal with storing user passwords so I prefer using OpenID.

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

#75

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

tsally wrote: post #68

tptacek wrote: post #66

Earlier quoted context omitted.

Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me). The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.

The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry. Given your history of quality and logical posts, I pretty much knew the comment wasn't directed towards me. I just wanted to go on record to be sure. I'm sorry as well, I should have just let it fly. Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me). They're lau…

They're doing it as we speak. They had a 5 hour down time that stretched out to 10 hours on Saturday night getting systems migrated; they're announcing batches of accounts converted in Twitter over the week.

(NB: I'm friendly with several 37s people online, and I've talked to them about what they're doing, and while I'll leave it to them to talk up their security, I think they're OK on this issue now).

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

#76

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

tptacek wrote: post #51

paulgb wrote: post #45

Earlier quoted context omitted.

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…

I've read your explanation of this problem several times in the past and only now I figured out (I think) the problem you are pointing out. This seems to be substance of your argument, as I understood it:

The computational expense of a brute-force attack against a hash is the lesser of (hash length, text length). Well-known hash functions (md5, sha*) are optimized for large blocks of text, which leads to two properties: 1) they are made fast 2) them being fast is not a problem - if the text is long the strength against the brute-force attack is determined by the hash length which is very respectable for sha256 or even sha512.

However, the passwords themselves are small - the typical password is 8 characters and assuming 7 bits per character you're looking at search space of 56 bit, at which point it doesn't matter if your hash is 64, 128 or 512 bit because your strength is 56 bit. The search space can be further reduced by accounting fr various password selection biases, for example phonetic bias, tack-number-at-the-end bias, keyboard layout bias and so on.

To deal with small search spaces we need algorithmically slow hash functions - their slowness is not a problem because text is small, but it's a benefit against the brute-force attack.

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

#77

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

epochwolf wrote: post #74

Nwallins wrote: post #63

Earlier quoted context omitted.

There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) So, is there any less sensitivity (security-wise) regarding the key, instead of the password?

It's more common to get access to the database through sql-injection rather than hacking the server. So having the encryption key on disk is more secure than plain text in a database but not much more. It's also possible for the encrypted passwords to be stored in a separate server that only provides a simple web service with two operations: update_password(email, password), mail_password(email) and store passwords h…

(a) You don't have to "hack the server" to read a config file that the web app can also read.

(b) Independent of all the other flaws that will get you arbitrary file read, if you don't know what the cases are where SQLI gets you arbitrary file read, you're probably not qualified to design your own password storage. I really mean that with all due respect.

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

#78

Post by tptacek » Tue, Dec 15, 2009, 4:03 AM UTC

DenisM wrote: post #76

tptacek wrote: post #51

Earlier quoted context omitted.

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…

I've read your explanation of this problem several times in the past and only now I figured out (I think) the problem you are pointing out. This seems to be substance of your argument, as I understood it: The computational expense of a brute-force attack against a hash is the lesser of (hash length, text length). Well-known hash functions (md5, sha*) are optimized for large blocks of text, which leads to two properti…

Yes. Think also of it this way: poor user password selection (and here we mean "ugh&8eat" is a weak password) sabotages the complexity of the attack, and adaptive hashing (like SCrypt) fixes that problem algorithmically.

Which is how it should work. Users shouldn't have to pick absurd passwords when the computer can do a better job of obscuring their password.

(Note: "them being fast", for "them" in SHA1, SHA256, etc, is not even considered a "problem"; it's considered a "huge feature", because these things are protecting individual data packets. It just happens that this primitive by itself is not useful for protecting passwords.)

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

#79

Post by ars » Tue, Dec 15, 2009, 4:06 AM UTC

makulit wrote: post #73

tptacek wrote: post #60

Earlier quoted context omitted.

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

Jmilikin already stated the config salt is not present, that the password IS 4 ASCII digits and he assumes a database breach. Isn't it up to the attacker to figure out the rest of the details? As an attacker, do you think he has a separate config salt in a file or a separate table or secondary system? That's why you DO spend 10 hours on attacking it if you want the results. His posting seems quite legitimite to me.

This is a learning exercise, not an attack. Posting some details is quite reasonable. I might spend lot of time on a real attack, if I want the passwords, but I won't for an exercise.

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

#80

Post by tptacek » Tue, Dec 15, 2009, 4:09 AM UTC

makulit wrote: post #73

tptacek wrote: post #60

Earlier quoted context omitted.

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

Jmilikin already stated the config salt is not present, that the password IS 4 ASCII digits and he assumes a database breach. Isn't it up to the attacker to figure out the rest of the details? As an attacker, do you think he has a separate config salt in a file or a separate table or secondary system? That's why you DO spend 10 hours on attacking it if you want the results. His posting seems quite legitimite to me.

He stated the opposite of what you said, so I wasted 0.9 seconds of runtime and 15 seconds of coding time verifying that he was not crazy enough to promise $1000 for trying 10,000 SHA1 iterations, which at the time seemed possible. He owes me 0.4% of my bill rate!

If your second graf is valid, then it is equally valid to say that rot13'ing your passwords before you hash them is an effective security measure, because you're right, I'd never guess you'd be that dumb.