title: The necessity of hiding the salt for a hash
body: <p>At work we have two competing theories for salts.  The products I work on use something like a user name or phone number to salt the hash.  Essentially something that is different for each user but is readily available to us.  The other product randomly generates a salt for each user and changes each time the user changes the password.  The salt is then encrypted in the database.</p>
  
  <p>My question is if the second approach is really necessary?  I can understand from a purely theoretical perspective that it is more secure than the first approach, but what about from a practicality point of view.  Right now to authenticate a user, the salt must be unencrypted and applied to the login information.  </p>
  
  <p>After thinking about it, I just don't see a real security gain from this approach.  Changing the salt from account to account, still makes it extremely difficult for someone to attempt to brute force the hashing algorithm even if the attacker was aware of how to quickly determine what it was for each account.  This is going on the assumption that the  passwords are sufficiently strong.  (Obviously finding the correct hash for a set of passwords where they are all two digits is significantly easier than finding the correct hash of passwords which are 8 digits).  Am I incorrect in my logic, or is there something that I am missing?</p>
  
  <p><strong>EDIT:</strong> Okay so here's the reason why I think it's really moot to encrypt the salt.  (lemme know if I'm on the right track).  </p>
  
  <p>For the following explanation, we'll assume that the passwords are always 8 characters and the salt is 5 and all passwords are comprised of lowercase letters (it just makes the math easier).</p>
  
  <p>Having a different salt for each entry means that I can't use the same rainbow table (actually technically I could if I had one of sufficient size, but let's ignore that for the moment).  This is the real key to the salt from what I understand, because to crack every account I have to reinvent the wheel so to speak for each one.  Now if I know how to apply the correct salt to a password to generate the hash, I'd do it because a salt really just extends the length/complexity of the hashed phrase.  So I would be cutting the number of possible combinations I would need to generate to "know" I have the password + salt from 13^26 to 8^26 because I know what the salt is.  Now that makes it easier, but still really hard.  </p>
  
  <p>So onto encrypting the salt.  If I know the salt is encrypted, I wouldn't try and decrypt (assuming I know it has a sufficient level of encryption) it first.  I would ignore it.  Instead of trying to figure out how to decrypt it, going back to the previous example I would just generate a larger rainbow table containing all keys for the 13^26.  Not knowing the salt would definitely slow me down, but I don't think it would add the monumental task of trying to crack the salt encryption first.  That's why I don't think it's worth it.  Thoughts?</p>
  
  <p>Here is a link describing how long passwords will hold up under a brute force attack:
  <a href="http://www.lockdown.co.uk/?pg=combi" rel="noreferrer">http://www.lockdown.co.uk/?pg=combi</a></p>