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

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

#101

Post by kwamenum86 » Tue, Dec 15, 2009, 6:00 AM UTC

tptacek wrote: post #78

DenisM wrote: post #76

Earlier quoted context omitted.

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…

But we force users to choose obscure passwords to discourage dictionary attacks (so I thought) not to protect them in case our dbs are hacked. A computer may be able to obscure a password better than the average user but at the end of the day the user still has to commit that password to memory, which may be why people stick with the same simple passwords to begin with.

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

#102

Post by tptacek » Tue, Dec 15, 2009, 6:06 AM UTC

frisco wrote: post #100

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…

My understanding was that hashing a hash was stupid because you've effectively limited your attacker's search space. That is, in the beginning the password or pass phrase can be any length (probably up to 255), but after hashing you've restricted it to a known length composed of known characters. Therefore, you've decimated the overall search space. It seems like iteratively rehashing your hash 1000 times would make…

A SHA1 hash is, what, 160 bits long? That's better than most AES keys. Nobody attacks passwords by directly attacking the SHA1 algorithm.

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

#103

Post by tptacek » Tue, Dec 15, 2009, 6:07 AM UTC

kwamenum86 wrote: post #101

tptacek wrote: post #78

Earlier quoted context omitted.

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…

But we force users to choose obscure passwords to discourage dictionary attacks (so I thought) not to protect them in case our dbs are hacked. A computer may be able to obscure a password better than the average user but at the end of the day the user still has to commit that password to memory, which may be why people stick with the same simple passwords to begin with.

Yes, and adaptive hashing makes those memorable passwords significantly more safe.

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

#104

Post by makulit » Tue, Dec 15, 2009, 6:30 AM UTC

tptacek wrote: post #98

makulit wrote: post #93

Earlier quoted context omitted.

Actually I thought I paraphrased it pretty well but to I guess a direct quote is better. "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." I do agree this is a learning exercise. I also agree that as an attacker you still have to make a lot of presumptions such as maybe they did use a k…

He implied he was using SHA1(nonce, password). He was actually using SHA1(k, nonce, password). You're taking a later clarifying comment he made and adding it to the main comment. But who cares? This is silly. Secure password schemes don't need to protect a key file to avoid being broken, and they don't need you to know how Merkle-Damgaard works to implement without blowing up. Any password scheme that has a "config s…

He said he was using SHA1 which to me is not an implication. Is SHA1(k.nonce,password) not a form of SHA1? All you had to do was say, with the information available, you would not have been able to determine the password.

On a different note, why aren't more webapps tracking login attempts? Is this too difficult to implement based on simple but sane "timeout" rules?

Also, if an attacker does have access to the db through an injection and is able to dump/download the db what is really stopping the attacker from using a multitude of cheap machines? I'm just a small shop and I turn up 19 or 20(half cab)u dual density servers(16 cores/u) every few months. So I'm looking at 320 cores that a 32 million record database distributed over is actually pretty small. Does any kind of encryption matter at that point? In this day, that kind of processing power is cheap.

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

#105

Post by gojomo » Tue, Dec 15, 2009, 6:41 AM UTC

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)?

They trust people and credentials -- it's not about the technical details. There's a great chapter in Randall Stross's "EBoys" about TriStrata -- which raised millions based on essentially nonsense claims of an "unbreakable" encryption technology.

(The chapter is excerpted at the bottom of this message: http://www.xent.com/FoRK-archive/april00/0460.html )

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

#106

Post by tptacek » Tue, Dec 15, 2009, 6:46 AM UTC

makulit wrote: post #104

tptacek wrote: post #98

Earlier quoted context omitted.

He implied he was using SHA1(nonce, password). He was actually using SHA1(k, nonce, password). You're taking a later clarifying comment he made and adding it to the main comment. But who cares? This is silly. Secure password schemes don't need to protect a key file to avoid being broken, and they don't need you to know how Merkle-Damgaard works to implement without blowing up. Any password scheme that has a "config s…

He said he was using SHA1 which to me is not an implication. Is SHA1(k.nonce,password) not a form of SHA1? All you had to do was say, with the information available, you would not have been able to determine the password. On a different note, why aren't more webapps tracking login attempts? Is this too difficult to implement based on simple but sane "timeout" rules? Also, if an attacker does have access to the db thr…

It takes 10 hours for two fast cores to attack one single password across 32MM BCrypt hashes with the default cost factor. What does 320 cores get you? 160 passwords in 10 hours, or 0.06% of /usr/share/dict/words. No, you cannot simply scale your way to a BCrypt cracker using cloud servers.

When you start worrying about attackers who will lease massive numbers of servers to crack your passwords, you dial up the cost on your hashes. You can do that transparently with BCrypt, migrating users as they log in. Every tiny incremental increase to the cost of a single login you make creates drastic cost increases for your attackers. You are on the right side of the scaling problem, the attacker is on the wrong side, and you can play the game indefinitely.

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

#107

Post by heresy » Tue, Dec 15, 2009, 7:49 AM UTC

tptacek wrote: post #82

ars wrote: post #72

Earlier quoted context omitted.

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

You are sending a crackable password hash on every request. Stop doing that. Create a session table, key it off a 48-byte random string from /dev/random, and store authenticators in that. In other words, JSESSIONID or RACK.SESSION or PHPSESSIONID or ASPSESSIONID are all stronger approaches than the one you've chosen. You are going through extra effort to make your system less secure. If the config salt is the second…

thanks. every time someone uses the password as input to some "secure" hash, i cry inside. why is the password even relevant to a user session identifier? it's not.

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

#108

Post by ars » Tue, Dec 15, 2009, 8:42 AM UTC

heresy wrote: post #107

tptacek wrote: post #82

Earlier quoted context omitted.

You are sending a crackable password hash on every request. Stop doing that. Create a session table, key it off a 48-byte random string from /dev/random, and store authenticators in that. In other words, JSESSIONID or RACK.SESSION or PHPSESSIONID or ASPSESSIONID are all stronger approaches than the one you've chosen. You are going through extra effort to make your system less secure. If the config salt is the second…

thanks. every time someone uses the password as input to some "secure" hash, i cry inside. why is the password even relevant to a user session identifier? it's not.

And the next time someone logs in as you, and clicks "keep me logged in" - and you have no way to un-log them in, you should also cry inside.

If the password is changed, all session identifiers must be invalidated. If it's a session table, delete all entries, if it's a hash - well your hash had better include the password somehow (a hash of the password hash, i.e. the one stored in the db, is fine, as long as changing the password changes the final hash).

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

#109

Post by ErrantX » Tue, Dec 15, 2009, 4:04 PM UTC

mikebo wrote: post #57

jmillikin wrote: post #47

Earlier quoted context omitted.

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.

If your webserver machines are so secure, why put them in the database at all?

You do put them on a web server. It just happens to run software optimized for extracting a particular entry from a large data set :)

Ironically the way you suggest is more secure: because to compromise it (assuming the web app is out of the equation for the moment) requires a system exploit. Whereas you have the added complexity of the database as an additional weak point.

EDIT: im confused about the downvote.. what in particular appears wrong (so I can explain it). Having Database software certainly lowers security on any system :) it's another failure point (any good security text book will explain that)

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

#110

Post by mattyb » Tue, Dec 15, 2009, 9:14 PM UTC

tptacek wrote: post #84

DenisM wrote: post #83

Earlier quoted context omitted.

Okay. So how much time does it normally take you to get this message across?

Here's a funny thing: every time this comes up, someone asks me if Whirlpool solves the problem. What is it with Whirlpool?

It creates long (512-bit) digests, and:

Even a small change in the message will (with an extremely high probability of 1-10^(-154)) result in a different hash, which will usually look completely different just like two unrelated random numbers do.

http://en.wikipedia.org/wiki/Whirlpool_(cryptography)

I used it for a while, then learned that using a fast hash, even looped plenty of times, is a bad idea for password storage when you have easy access to B/scrypt.