Big salt, little salt, smoked salt, epsom salt. Nothing you can do with your salt protects you from the attack that bcrypt protects you from, which is the same attack that harvested passwords from the Gawker hashes.
Can you provide more detail? That doesn't mesh with my understanding. The Gawker hacks are different in a couple of ways.
First, they had access to the complete Gawker database, could have downloaded it and run their attacks on their side. They still would have needed to use blowfish/bcrypt (afaik), but your high rounds are useless if an attacker gets the actual data out of your infrastructure, just like they are with normaler hashes.
Second, the Gawker guys had no salting, and they used DES, which, as you know, was deprecated before many HN users were born. This made cracking the passwords really easy ... not that it would be that much harder with a conventional salting mechanism or even with bcrypt.
I was not contending that bcrypt is not like really great, just that it's not "completely irresponsible" to not use bcrypt or scrypt. bcrypt is still vulnerable to dictionary attacks, the only difference is the amount of time it will take to get everyone's password out, which, again, is useless in a case like gawker where the dumps are distributed all over the internet for anyone with an interest to peruse.
You're wrong. DES crypt(3) hashes have had salts since the 1970s. Capture of complete password databases is exactly why you hash passwords instead of storing them plaintext. I don't think you have the requisite background to hold a strong opinion about this subject; you should just take our word for it.
I think there's a communication barrier here, but I'll just let it go for now. Gawker's passwords were unsalted according to the first few hits on Google and that's all the research I did on it, not that it really makes a difference since a salt isn't the point here anyway; the point is that you don't have to be using bcrypt to be a responsible datakeeper and that bcrypt isn't an end-all as it's made out to be.
You're right that I don't have a very deep cryptographic background, but from everything I've seen and read, dictionary attacks still work on bcrypt'd passwords, just more slowly than otherwise. This is the part I want to know if I'm wrong about; is there some a reason a dictionary attack doesn't work on bcrypt? I understand that it will take longer to get 100% password recovery out of a bcrypt'd database than a database hashed with SHA-256 or SHA-512. Let's say that's not relevant because our theoretical attacker has A) a computer from the future which is fast enough to blow through bcrypt just as quickly as SHA-* or MD5; or B) is only interested in one user's password, so the expense is bearable. In these situations, does bcrypt provide extra protection that isn't routinely implemented in a standard hash?
My understanding is that bcrypt does not provide much besides the slowdown. I'm not trivializing the slowdown, I understand completely why it is beneficial to keep passwords away from bad guys as long as possible after a data leak. I am merely saying that if I'm correct and the only thing standing between bcrypt and SHA-* for a captured password database is X iterations of silicon, I don't really see using SHA-* hashes as "completely irresponsible".
Dictionary attacks can be made infeasible against bcrypt. DES crypt has a 12-bit salt. Using SHA hashes is insecure. It isn't the end of the word. Knowingly choosing to use a naked salted SHA hash instead of a "stretched" SHA has or bcrypt or scrypt or PBKDF is, in fact, irresponsible.
I would have ignored your original comment and avoided pedantry except for your original assertion that your salting did something to mitigate the risk of not using bcrypt. It does no such thing. There's nothing else for us to argue about.
Comments
Big salt, little salt, smoked salt, epsom salt. Nothing you can do with your salt protects you from the attack that bcrypt protects you from, which is the same attack that harvested passwords from the Gawker hashes.
Can you provide more detail? That doesn't mesh with my understanding. The Gawker hacks are different in a couple of ways.
First, they had access to the complete Gawker database, could have downloaded it and run their attacks on their side. They still would have needed to use blowfish/bcrypt (afaik), but your high rounds are useless if an attacker gets the actual data out of your infrastructure, just like they are with normaler hashes.
Second, the Gawker guys had no salting, and they used DES, which, as you know, was deprecated before many HN users were born. This made cracking the passwords really easy ... not that it would be that much harder with a conventional salting mechanism or even with bcrypt.
I was not contending that bcrypt is not like really great, just that it's not "completely irresponsible" to not use bcrypt or scrypt. bcrypt is still vulnerable to dictionary attacks, the only difference is the amount of time it will take to get everyone's password out, which, again, is useless in a case like gawker where the dumps are distributed all over the internet for anyone with an interest to peruse.
Please correct me if I'm wrong.
You're wrong. DES crypt(3) hashes have had salts since the 1970s. Capture of complete password databases is exactly why you hash passwords instead of storing them plaintext. I don't think you have the requisite background to hold a strong opinion about this subject; you should just take our word for it.
I think there's a communication barrier here, but I'll just let it go for now. Gawker's passwords were unsalted according to the first few hits on Google and that's all the research I did on it, not that it really makes a difference since a salt isn't the point here anyway; the point is that you don't have to be using bcrypt to be a responsible datakeeper and that bcrypt isn't an end-all as it's made out to be.
You're right that I don't have a very deep cryptographic background, but from everything I've seen and read, dictionary attacks still work on bcrypt'd passwords, just more slowly than otherwise. This is the part I want to know if I'm wrong about; is there some a reason a dictionary attack doesn't work on bcrypt? I understand that it will take longer to get 100% password recovery out of a bcrypt'd database than a database hashed with SHA-256 or SHA-512. Let's say that's not relevant because our theoretical attacker has A) a computer from the future which is fast enough to blow through bcrypt just as quickly as SHA-* or MD5; or B) is only interested in one user's password, so the expense is bearable. In these situations, does bcrypt provide extra protection that isn't routinely implemented in a standard hash?
My understanding is that bcrypt does not provide much besides the slowdown. I'm not trivializing the slowdown, I understand completely why it is beneficial to keep passwords away from bad guys as long as possible after a data leak. I am merely saying that if I'm correct and the only thing standing between bcrypt and SHA-* for a captured password database is X iterations of silicon, I don't really see using SHA-* hashes as "completely irresponsible".
Dictionary attacks can be made infeasible against bcrypt. DES crypt has a 12-bit salt. Using SHA hashes is insecure. It isn't the end of the word. Knowingly choosing to use a naked salted SHA hash instead of a "stretched" SHA has or bcrypt or scrypt or PBKDF is, in fact, irresponsible.
I would have ignored your original comment and avoided pedantry except for your original assertion that your salting did something to mitigate the risk of not using bcrypt. It does no such thing. There's nothing else for us to argue about.