title: How does password salt help against a rainbow table attack?
body: <p>I'm having some trouble understanding the purpose of a salt to a password.  It's my understanding that the primary use is to hamper a rainbow table attack.  However, the methods I've seen to implement this don't seem to really make the problem harder.</p>
  
  <p>I've seen many tutorials suggesting that the salt be used as the following:</p>
  
  <pre><code>$hash =  md5($salt.$password)
  </code></pre>
  
  <p>The reasoning being that the hash now maps not to the original password, but a combination of the password and the salt.  But say <code>$salt=foo</code> and <code>$password=bar</code> and <code>$hash=3858f62230ac3c915f300c664312c63f</code>.  Now somebody with a rainbow table could reverse the hash and come up with the input "foobar".  They could then try all combinations of passwords (f, fo, foo, ... oobar, obar, bar, ar, ar).  It might take a few more milliseconds to get the password, but not much else.</p>
  
  <p>The other use I've seen is on my linux system.  In the /etc/shadow the hashed passwords are actually stored <em>with</em> the salt.  For example, a salt of "foo" and password of "bar" would hash to this: <code>$1$foo$te5SBM.7C25fFDu6bIRbX1</code>.  If a hacker somehow were able to get his hands on this file, I don't see what purpose the salt serves, since the reverse hash of <code>te5SBM.7C25fFDu6bIRbX</code> is known to contain "foo".</p>
  
  <p>Thanks for any light anybody can shed on this.</p>
  
  <p><strong>EDIT</strong>:  Thanks for the help.  To summarize what I understand, the salt makes the hashed password more complex, thus making it much less likely to exist in a precomputed rainbow table.  What I misunderstood before was that I was assuming a rainbow table existed for ALL hashes.</p>