title: How can I store a salted password hash if I have only one database column?
body: <p>I've read a number of SO questions on this topic, but grokking the applied practice of storing a salted hash of a password eludes me.</p>
  
  <p>Let's start with some ground rules: </p>
  
  <ul>
  <li>a password, "foobar12" (we are <strong>not</strong> discussing the strength of the password).</li>
  <li>a language, Java 1.6 for this discussion</li>
  <li>a database, postgreSQL, MySQL, SQL Server, Oracle</li>
  </ul>
  
  <p>Several options are available to storing the password, but I want to think about one (1):</p>
  
  <blockquote>
    <p><strong>Store the password hashed with random salt in the DB, one column</strong></p>
  </blockquote>
  
  <p>The automatic fail of plaintext storage is not open for discussion. :) Found on SO and elsewhere are solutions with MD5/SHA1 and use of dual-columns, both with pros and cons.</p>
  
  <p>MD5/SHA1 is simple. MessageDigest in Java provides MD5, SHA1 (through SHA512 in modern implementations, certainly 1.6). Additionally, most RDBMSs listed provide methods for MD5 encryption functions on inserts, updates, etc. The problems become evident once one groks "rainbow tables" and MD5 collisions (and I've grokked these concepts).</p>
  
  <p>Dual-column solutions rest on the idea that the <code>salt</code> does not need to be secret (grok it). However, a second column introduces a complexity that might not be a luxury if you have a legacy system with one (1) column for the password and the cost of updating the table and the code could be too high.</p>
  
  <p>But it is <em>storing the password hashed with a random salt in single DB column</em> that I need to understand better, with practical application.</p>
  
  <p>I like this solution for a couple of reasons: a salt is expected and considers legacy boundaries. Here's where I get lost: <strong>If the salt is random, and the password plus salt are hashed to produced a one-way value for storing, how can the system <em>ever</em> match a plaintext password and a <em>new</em> random salt?</strong></p>
  
  <p>I have theory on this, and as I type I might be grokking the concept: Given a random salt of 128 bytes and a password of 8 bytes ('foobar12'), it could be programmatically possible to remove the part of the hash that was the salt, by hashing a random 128 byte salt and getting the substring of the original hash that is the hashed password. Then re hashing to match using the hash algorithm...?</p>
  
  <p>So... any takers on helping. :) Am I close?</p>