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