email address as password salt?

Question

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

Answer 1

If e-mail address never changes than it's fine. I prefer a random salt myself since this is information no one knows. If someone knows your way the salt is done and got the hash and got the hash method you use than he can generate list of hashes based on that e-mail to retrieve to original password. I doubt someone goes trough all this effort unless it's a really important application

Answer 2

To increase security, it would be better to use a random salt. Email addresses can be found out quite easily, thus reducing the effectiveness of the salt. (Clarified in comments)

Answer 3

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).

Answer 4

I'm not a cryptography expert, however there are 3 things in particular that strike me as possibles issues with this suggestion.

1. As Mark points out, the email may change, however the salt needs to remain the same for a given password (otherwise you won't be able to check the validity of the password).
2. The size of email addresses is variable, and I imagine that it is important that the salt be larger than a certain size.
3. Using an email address makes the salt much more predictable, which is usually a bad thing in cryptography.

I don't know if any of these is an issue or not, however the thing about cryptography is that often nobody knows until someone has devised an exploit (and by then its too late) - so my advice would be to err on the side of caution and not use email addresses as salt.

Answer 5

As others already mentioned, salt should best be random. The purpose of a salt is to prevent rainbow table attacks using pre-computed hash dictionaries.

Assuming an attacker gets to know the hashed passwords and salts from your database, if the salt is "a74kd%$QaU" and the password is "12345", will he be able to crack it using a rainbow table? No, even if the password is weak, the attacker won't have a pre-computed hash dictionary at hand for your random salt.

If you however use a non-random salt like the user id or email it is somewhat more likely that someone already created a rainbow table for that salt, hoping to find a user with username "john" or the email "[email protected]"¹

¹WPA security for WLANs uses the SSID of the access point as a salt. Too bad, someone already pre-computed hashes for the most frequent SSID names.

Answer 6

Ophcrack (which is what most attackers would probably use, depending on your encryption function) doesn't contain tables with special characters like '.' or '@' unless you get to the biggest ("extended") tables. So using an email would probably be better than many other salts.