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

81–90 of 112 posts

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

#81

Post by shrughes »

jmillikin wrote: post #14
tptacek wrote: post #2

Note that if you store your passwords in a fast hash format like salted SHA1, an attacker with 32MM database rows can publish a very credible sample of usernames and passwords, and leave you scrambling to explain how the breach isn't really as bad as it looks. Not a great position to be in. The right answers to this problem are BCrypt, SCrypt, PBKDF, or (at a minimum) salted "stretched" SHA1, iterated many thousands…

What's wrong with using a salted hash? Assuming a competent implementation, it should be computationally infeasible to brute-force any digests in less than a few billion years using current models of computation. I'm particularly curious about how using (for example) BCrypt will prevent brute-forcing "12345", "password", or any of the other simple strings many people use.

What's wrong with using a salted hash?

Because you've been assuming that the database will be breached and that no other kind of attack can happen.

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

#82

Post by tptacek »

ars wrote: post #72
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…

> 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 term hashed, the scheme has a basic crypto flaw, one you can't make if you just use BCrypt or PBKDF like a reasonable developer instead of designing your own vanity scheme.

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

#83

Post by DenisM »

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…

Okay.

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

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

#84

Post by tptacek »

DenisM wrote: post #83
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…

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?

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

#85

Post by tptacek »

DenisM wrote: post #53
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…

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.

There's Bcrypt.NET, which looks reasonable to me. It's a direct port of jBCrypt (Java).

I don't blame you for not wanting to use unverified third party security code though. RFC2898 is fine.

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

#86

Post by epochwolf »

tptacek wrote: post #77
epochwolf wrote: post #74

Earlier quoted context omitted.

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.

Yikes, I didn't realize databases included the ability to edit the filesystem.

I don't ever intend to get into the area of writing my own password storage until I learn a lot more in the area of security. I am only aware of how little I don't know about what I don't know.

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

#87

Post by tptacek »

jmillikin wrote: post #54
harpastum wrote: post #49

Earlier quoted context omitted.

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…

Calculating a BCrypt hash with the default cost factor takes about as long as reading an uncached file off a conventional filesystem. What a silly thing to try to optimize. Really? It's killing you to spend 100ms on password hashing? Ok, dial it down to 50ms. BCrypt is tunable.

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

#88

Post by sabat »

tptacek wrote: post #2

Note that if you store your passwords in a fast hash format like salted SHA1, an attacker with 32MM database rows can publish a very credible sample of usernames and passwords, and leave you scrambling to explain how the breach isn't really as bad as it looks. Not a great position to be in. The right answers to this problem are BCrypt, SCrypt, PBKDF, or (at a minimum) salted "stretched" SHA1, iterated many thousands…

It's funny -- I remember a self-appointed security guru here saying that the fact that 37 Signals doesn't encrypt passwords was perfectly fine, a minor detail. You can't half-ass basic security measures. It's like leaving your car unlocked in east Oakland.

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

#89

Post by sabat »

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…

37 Signals is on record as having stored passwords in plain text. They thought it was just fine at the time. I'm glad to hear they finally caught up with the new millenium.

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

#90

Post by tptacek »

epochwolf wrote: post #86
tptacek wrote: post #77

Earlier quoted context omitted.

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

Yikes, I didn't realize databases included the ability to edit the filesystem. I don't ever intend to get into the area of writing my own password storage until I learn a lot more in the area of security. I am only aware of how little I don't know about what I don't know.

Yep.

    CREATE TABLE foo ( x TEXT );
    LOAD DATA INFILE "/etc/whatever" INTO TABLE foo ; 
    SELECT x FROM foo;
Did you know about INTO DUMPFILE in SELECT statements? =)
Post reply on HN