I remember a while back that the Drupal community had an issue with salting the password because someone thought it was more secure than storing the md5 directly into the database. The idea was absolutely ridiculous, because once the salt (or getting the salt) is known, the attack is only marginally more difficult than if you never salted your md5. Salting is only good in a limited circumstances where the salt is private and if the server is compromised then the salt is also compromised. For instance if the salt is stored in a file, then the attacker would have to have access to all the files on your server, which makes it a bit more difficult. But if they can get to your database, the odds are pretty good that they have access to your filesystem where the statement for how to get to your database exists.

V Bulletain does something rather interesting, instead of sending a plaintext password via its login form, it instead sends an MD5 hash through an onsumit javascript function. This might sound like a great idea, until you assume that any attacker has a rainbow table at their disposal. They can therefore launch an attack on the site, as well as figure out what the password was just as if you had not hashed it. Because of the prevalence of standard md5 rainbow tables, I would say that hashing anything is almost useless. Only the least sophisticated attackers would be deterred by an MD5 hash of a password.

Another idea might be to salt the password with some known information about the user. Salting the md5 is useful, but the javascript would have to know what the salt was and this would void much protection the salt provides because the attacker can already get to the algorithm used to generate the md5 hash and therefore they can generate rainbow tables too. The only thing standing in their way is the amount of time and that can be shorted by extending slightly more resources via Amazon or some such service.

A non-predicable salt, that is each unique salt per user is useful because it means the attacker has to go through quite a bit more work in order to compromise the site fully. Getting the password of user A does not mean you have the password of every other use on the site. There are a number of pieces of information that you can use such as the username, but whatever information use, the user will have to provide it along with the password, therefore username seems like a good idea along with some defined constant.

The only problem with the approach is that if you need to regenerate the password, you must do it from within php, because mysql only has a standard md5 function built into it. This is really why the community at Drupal decided not the salt the md5, the protection often is very limited then what you have otherwise -- though as I have shown above, a bit of work can go a long way to making it harder for the attacker to compromise the site wholesale.