Help needed in grokking password hashes and salts

Posted by javafueled on Stack Overflow See other posts from Stack Overflow or by javafueled
Published on 2010-05-12T02:49:10Z Indexed on 2010/05/12 2:54 UTC
Read the original article Hit count: 314

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.

Let's start with some ground rules:

  • a password, "foobar12" (we are not discussing the strength of the password).
  • a language, Java 1.6 for this discussion
  • a database, postgreSQL, MySQL, SQL Server, Oracle

Several options are available to storing the password, but I want to think about one (1):

Store the password hashed with random salt in the DB, one column

Found on SO and elsewhere is the automatic fail of plaintext, MD5/SHA1, and dual-columns. The latter have pros and cons

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

Dual-column solutions rest on the idea that the salt 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.

But it is storing the password hashed with a random salt in single DB column that I need to understand better, with practical application.

I like this solution for a couple of reasons: a salt is expected and considers legacy boundaries. Here's where I get lost: if the salt is random and hashed with the password, how can the system ever match the password?

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

So... any takers on helping. :) Am I close?

© Stack Overflow or respective owner

Related posts about encryption

Related posts about salt