Earlier quoted context omitted.
My answer to this question is effective but very self-serving.
Train our runtimes to detect and reject attempts to store user passwords in plaintext?
I think the correct answer is 'hire tptacek' :)
All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
21–30 of 112 posts
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#22Earlier 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…
What do you think about halting password puzzles?
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#23Note 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.
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.
But with SHA1, you can feasibly do large combinations of phonemes with numbers and punctuation across millions of accounts. People with passwords like "ugh8&eat" will lose their accounts.
You can tune BCrypt so that just "12345", by itself, is too painful to run across 32MM rows to be worth a PR stunt.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#24Earlier 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…
Thanks for that!
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#25Earlier 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…
What do you think about halting password puzzles? http://crypto.stanford.edu/~xb/security07/index.html
I think anything ending in "KDF" gives me warm fuzzies, and that whatever you code in already has a library for BCrypt.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#26Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#27What's the plumber equivalent of storing passwords in plaintext, the things where if you heard that a plumber did X, you would be in complete shock at their negligence?
How about: Install a drain without a vent.
Why do you want to know?
Edit: I picked this example carefully. Someone who knowns nothing about plumbing will not be shocked at this, having no idea what it is (until it's explained to them). Just like someone who is not a programmer will have no idea what the problem with plain text password is (until it's explained to them).
PS. A drain without a vent (or at least an anti-siphoning device) can be life threatening.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#28Note 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…
Does using a unique salt for each user help here? Is there a non-obvious reason why that approach is bad?
I Am Not A Cryptographer, so take this with a grain of salt. Using a unique salt for each user "helps", but is still insecure. The problem is that hash functions such as SHA or MD5 are designed to be very fast. This means that even with unique salts it is still fairly trivial to try a large number of passwords on a large number of users and crack many or them.
The parent poster has the right idea. For passwords, use bcrypt, scrypt, PBKDF, or a stretched hash.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#29Earlier 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…
"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 would have to be extremely slow (minutes or hours per password) to prevent somebody from running it against "password", "12345", etc for every row in the table. And that's the only kind of attack worth preventing -- if somebody can brute-force a 20-character alpha-num-symbol password in realtime, your choice of digest algorithm is irrelevant.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#30Earlier 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…
"Agile Web Development With Rails", Chapter 11, Administration