Email address as password salt?_问答_开发者_运维开发者技术经验分享

Is it a bad idea to use an email address as t开发者_如何转开发he salt for a password?

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.

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

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).
The size of email addresses is variable, and I imagine that it is important that the salt be larger than a certain size.
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.

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)

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 "john.doe@example.com"¹

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

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.

Like all things security-related, the answer depends on the question, which didn't include information on how secure you want the system to be. The most secure building is one with no windows or doors; it's also the most useless building.

From the highest level: no it's not a bad idea. It's not a great idea either. However, it may be good enough -- or more than good enough -- for your application.

If someone has a rainbow table for a specific email address, are you going to be able to stop them by hashing a password with a random salt? Good hackers take the path of least resistance, which may include getting root access to your system and downloading the salt and user tables. (Are they separately secured?) If so, they have until a password change to match a hash, regardless of the system-enforced consecutively failed login attempt limit or what you chose for salt.

How much more complexity arises from random salt in your application? How determined a hacker are you trying to thwart? What other measures -- maximum consecutive failure lockout, forced password expiration periods, ingress and DoS alerts, firewalls, etc. -- do you have in place? The answer lies somewhere in the convergence between the answers to those questions and maybe others as well.