Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

So, reading through this article: it says that storing the salt is fine in plain text because it renders the lookup/rainbow tables ineffective. I get that, but why not generate the salt from the submitted password and then never store that separately either?

Something like this:

$pass = '12345';
$salt = '';
// generate the salt somehow... probably not like this
$hash1 = hash('md2',$pass);
$hash2 = hash('md4',$pass);
for($i = 0; $i < strlen($hash1); $i += 2){
  $salt .= $hash1{$i} | $hash2{$i};
// hash the results
$hashedPass = hash('bcrypt', $salt . $pass);
share|improve this question

marked as duplicate by Gilles, Adi, TildalWave, AJ Henderson, NULLZ Jun 3 '13 at 21:33

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

up vote 7 down vote accepted

If the salt is a function of the password, then two exact passwords will produce the same hash.

For an arbitrary hashing function H() and an arbitrary salt generation S(Password), then

H("Password_1", S("Password_1")) = H("Password_1", S("Password_1"))

While if you use a random salt generation function RS() then

H("Password_1", RS()) != H("Password_1", RS())

As an attacker, nothing can make you happier than seeing two (or more) hashes used in two (or more) different accounts. This means at least one of two things

  1. The password is weak (because two different users chose the same password), then the attacker could concentrate his computational cracking powers on those hashes.

  2. The attacker can attack two (or more) accounts using the same computational effort only once.

share|improve this answer
Nice explanation! – David Jun 3 '13 at 19:39
Given a large dataset, an attacker could also launch a statistical attack to recover plaintext password based on password frequency. If I have a list of thousands or millions of plaintext passwords and their relative frequencies (or simply a ranking) and a somewhat large dataset of hashed passwords (using the H(x,S(x)) method) then I can map the frequencies of a hash to the frequency of plaintext passwords. – pdubs Jun 3 '13 at 20:17
@pdubs Fantastic input! +1 – Adi Jun 3 '13 at 20:27

It looks like you're talking most specifically about web applications [since your example code is in PHP]. Like the other poster said, taking the salt directly from the password itself poses an increased security risk when two users chose the same password. However, taking the salt from the Username (and not allowing duplicate usernames) is a solution to this issue.

In linux applications that authenticate using login credentials (ssh, ftp, etc), applications can obtain the salt from the /etc/passwd file.

Generally you want each salt to be unique. If you are taking a salt from the unique username but you are not using the entire username as the salt it is possible that you'll salt multiple passwords with the same salt. Storing the salt in plain text isn't a security threat when the salts are unique - however when the salts are the same the attacker simply needs to reverse the salting algorithm and he may begin cracking passwords.

Unix time stamps are a traditional salt in web applications but these must be stored in the database (if you wish, you may store the base64 of the salt using the native PHP functions base64_encode()/base64_decode() for added security).

share|improve this answer
I don't think this is a particularity great idea. The reason you want your salt random (unpredictable) is that you don't want the attacker to pre-compute the hashes before the actual attack. If the attacker knows that you have a username root, then he can simply generate a rainbow table for H("BRUTE_PASS" + "root"). – Adi Jun 3 '13 at 20:18
@Adnan, I don't think you read my post at all. Obviously you want the salt to be unpredictable. I wasn't referring to using the using the login username as the salt, I was simply saying that many applications that use login credentials take their salt from /etc/passwd. I disagree with your point. How would an attacker know that the username is the salt? If the attacker has access to the database and source code, which should be assumed, then any account can be cracked regardless of the salt (root or DhcH3jk3732). Using the username is secure if they are unique. This is a web app, not linux. – Charles Addis Jun 3 '13 at 21:53
@Adnan, it is not plausible that an attacker would assume that your salts are your usernames and begin trying to crack them as they would need to know the salting algorithm you used (not all passwords are salted the same way). This would be a long and tedious process given that each account has a unique salt. If the attacker has access to the source code and database/salt value then your security has already been compromised. – Charles Addis Jun 3 '13 at 22:00
I'm sorry, I have no idea where to start. Your answer and comments are just a viscous mixture of misconceptions and false information with a pinch of Security by Obscurity. A- "Obviously you want the salt to be unpredictable." How is a salt derived from a username not predictable? B- "How would an attacker know that the username is the salt?" Well, you've just recommend it it on a public site. C- If the attacker has access to the source code and database/salt value then your security has already been compromised This is exactly why you salt and hash your passwords! – Adi Jun 3 '13 at 23:10
“Using a random number generator, however, you run the chance of duplicate salts.” No you don't. If you get duplicate salts then either you aren't using a proper RNG, or your salt is too short, or your system has been running for a few billion years. “A way that is not easily replicated (by slicing it, shifting letters, replacing certain chars, etc)”… Words fail me. This isn't security, it's children playing with decoder rings. – Gilles Jun 4 '13 at 9:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.