Salt and hashing, why not use username?

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 be开发者_开发技巧hind 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:

• The user name does not change when the user changes his password. An attacker seeing the old hashed password and the new hashed password may attack both at a cost less than twice the cost of attacking one.
• At a given time, user names are unique system-wide, not world-wide. There are many "bob"s out there (in a Unix system, consider "root"). Using the user name may allow an attacker to attack several systems simultaneously.

Salt entropy is not really important, except in so much as it ensures uniqueness in a random generation setting.

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.

How about:

Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?

That would seemingly

1. have the advantage of not needing to store the salt as it can be dynamically calculated,

2. while still having good entropy (hash-based instead of plaintext), and

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