Question

Is it a bad idea to use an email address as the salt for a password?

Answer 1

EDIT:
Let me refer you to this answer on Security StackExchange which explains a lot of details about password hashing and key derivation.

Bottom line: Use a secure established password hashing scheme that is somehow resource-intensive to protect against brute-force attacks, but limit the number of permitted invocations to prevent denial-of-service (DoS) attacks.

If your language library has a function for it, verify on upgrades that it does what it is supposed to do, especially if it’s PHP.

The answer below is left for historical reasons.

You could use the user’s login name as a salt which might be less likely to change than an e-mail address (EDIT: 0xA3 correctly pointed out, this is less secure than using the e-mail address because login names tend to be easier to guess, and some are quite commonly used such that rainbow tables may already exist for them, or could be reused for other sites).

Alternatively, have a database column where you save the salt for the password.
But then, you could as well use a random user-specific salt just as well which is harder to guess.

For better security, you could use two salts: A user-specific one and a system-wide one (concat them, then hash the salts with the password).

By the way, simple concatenation of salt and passwords might be less secure than using HMAC. In PHP 5, there’s the hash_hmac() function you can use for this:

$salt = $systemSalt.$userSalt;
hash_hmac('sha1', $password, $salt);

EDIT: Rationale for a system-wide salt: It can and should be stored outside the database (but back it up. You won’t be able to authenticate your users if you lose it). If an attacker somehow gets to read your database records, he still cannot effectively crack your password hashes until he knows the system-wide salt.

EDIT (slightly off-topic):
A further note on the security of password hashes: You might also want to read Why do salts make dictionary attacks ‘impossible’? on hashing multiple times for additional protection against brute-forcing and rainbow table attacks (though I think that repeated hashing may introduce additional opportunities for denial-of-service attacks unless you limit the number of login attempts per time).

NOTE

Considering the rise of multi-purpose multi-core systems (graphics cards, programmable micro-controllers etc.), it may be worth using algorithms with high computation effort along with salts to counter brute-force cracking, e.g. using multiple hashing like PBKDF2. However, you should limit the number of authentication attempts per time unit to prevent DDoS attacks.

One more thing: Another main rationale for using a “custom” hashing built on widely-used standards rather than a widely-used pre-built function was PHP itself which has proven itself to be not trustworthy at all when it comes to implementing security-related stuff, be it the not-so-random random number generators or a crypt() function that does not work at all under certain circumstances, thereby totally bypassing any benefits that a compute- or memory-intensive password hashing function ought to bring.
Due to their deterministic outcomes, simple hash functions are more likely to be tested properly than the outputs of a key derivation function, but your mileage may vary.