I must confess to being largely ignorant on most of the high-tech security issues relevant for web applications, but there is one thing I at least thought I could ask because it is a direct question with (hopefully) a concrete answer.
Take this website: http://www.15seconds.com/issue/000217.htm
It shows a bit down that they store the salt value in the table, I understand the principles and the math behind using a salt, but I'm wondering this:
- Why did they not just use the username as a salt value instead of generating one?
The point of the salt is to be unique. The salt is meant to prevent attack cost sharing, i.e. an attacker trying to attack two hashed passwords for less than the twice the cost of attacking one.
One solution to ensure uniqueness is to generate a random salt in a wide enough space. Therefore, getting twice the same salt for two distinct password instances is sufficiently improbable that it will not happen in practice.
The user name is not adequately unique:
Salt entropy is not really important, except in so much as it ensures uniqueness in a random generation setting.
How about:
That would seemingly
while still having good entropy (hash-based instead of plaintext), and
provides a salt that's as long as a cryptographic hash eg 128-512 bits?
One problem would be if the system allowed two user to have the username and password (wouldnt happen with email addr though), but are there any other problems with this scheme?
Because user names have lower entropy than a random salt, so they spread your hashes around less than a proper salt does.
Not that the example on that page is very spectacular anyway. I always just generate a GUID and use that.
I suspect it's all down in the noise as far as real-life security is concern, and even quite small amounts of per-user salt make a big difference to security, with very small improvements as the salt gets more complex.