@morbiuswilters said:
Because it is twice as slow. Or do it a million times. That's the entire point of a password hash--it shouldn't be fast.
Of course your point above is true on some level -- that's the whole point of cryptography. However, the salt+hash technique is well accepted in the real world as a "good enough" solution to the problem for the example I gave, which is web servers. On a web server, you don't have the option of sitting there locking up the CPU for a long time for each user login. Processing resources are not infinite, and thus we have to find real world solutions.
@morbiuswilters said:
@sidecomment said:
One of the nice things about the hash+salt scheme when properly implemented is that the output of a particular hash function will have fixed width. So you could store the hash output as binary data in a database, or base 64 encode it and put it in XML, etc. The width of a password entered has no relationship to the storage requirement for the hash. The latter is known and set deterministically.
NO NO NO NO NO NO. Goddammit, stop spreading your ignorance. A fixed-length output is not a benefit.
Cut out the nasty attitude, please. The "benefit" I referred to (of a
fixed length output) was referring to convenience of storage, not
security. It's nice when setting up the hash column of your user table
to know exactly how many bytes are required.
@sidecomment said:
And (once again) the hash+salt scheme when properly implemented (i.e. just to be clear, "hash(pw+salt)") is that it is _not_ susceptible to dictionary attacks, which is where morbiuswilters' post was misleading (are we dead yet?).
@morbiuswilters said:
NO NO NO NO NO NO NO NO. Lookup dictionary attack, please. It is not (necessarily, at least) a pre-computed attack. The "dictionary" is the list of likely candidate passwords to try. It can just as easily be run with or without a salt. Salts are important at defeating pre-computing attacks, but that is not the primary concern when your hashing algorithm can be brute forced at a rate of 500 million hashes a second. Okay? In fact, dictionary attacks would be the prime candidate for cracking a password database that used individual salts because rainbow tables would be useless. "Dictionary attack" and "rainbow table" are not synonymous.
I know what a dictionary attack is. I guess I interpreted your post as highlighting a flaw related to the hash+salt approach, whereas it looks like all you meant to say is that any password based system has a weak point that (individual) weak passwords can be guessed. Fair enough, I guess I misunderstood you.
What I was talking about, and what the hash+salt approach addresses, is the attack vector of database access (think SQL injection).
If you use plaintext passwords, then they are trivially accessible -- no dictionary attack
needed.
If you just hash the passwords, then dictionary attack of
the database is possible, revealing lots of peoples' passwords.
If you use proper hash+salt, then even having full database access is not a useful attack vector to compromise the system. That's what I meant about the NSA, etc.
So talking about this totally separate attack vector that admittedly still exists (individual password guessing via dictionary attack) doesn't really have anything to do with your decision about password storage -- it's misleading and inappropriate to even suggest that it has something to do with the decision of password storage. So my point there still stands.
P.S. MD5 is generally deprecated these days. People should use SHA1 or better. Not sure why you mentioned MD5 in your reply. Is that what you use? :)