What'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?
All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
11–20 of 112 posts
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#12Earlier quoted context omitted.
Didn't Reddit do something very similar?
Many do. E.g. 37signals.
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
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#13Note 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'd be interested in knowing the answer to this too.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#14Note 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.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#15This 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…
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?
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#16Note 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?
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 optimized loops for brute forcing passwords. "Salts" do nothing to slow this attack down, because they add insignificant time (really, none) to a single hash iteration.
Hashes like MD5, SHA1, and even SHA256 are designed to be fast. To succeed, they need to be able to handle multi-gigabit per-packet hash rates. They are designed explicitly both to be fast on general-purpose hardware and to be straightforward to optimize in purpose-built hardware. This is a bad, bad property for a password hash.
BCrypt is "optimized" to be slow - tuneably slow. SCrypt improves on BCrypt by being both slow on general purpose hardware and resistant to simple hardware speedups. PBKDF and "stretched" SHA1 are very simple contructions that are weaker than BCrypt and SCrypt but more buzzword compliant. All of them make it difficult to recover hundreds of thousands of passwords from a database dump.
See:
http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#17Note 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?
The salt is used for the original encryption, after which the plaintext is thrown away, then when you need to compare what the user enters next time, you use the same salt with the password entered every time.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Edit: On second thought, I might have misread the question, perhaps you're intending to store the unique salt for each user, although that seems impractical to me since it would have to be just as obtainable as the password database.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#18Earlier quoted context omitted.
Many do. E.g. 37signals.
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 word) is a bad thing.
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#19What'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?
[deleted]
Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
#20Note 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.
[deleted]