What are the most common password salting methods?

Question

I learned that the Sun guys used the login name as salt for password hashing. Is this a common approach? What are the most common salt values?

Answer 1

Using the login name as salt is common but not really recommended: it does only part of the job. The point of a salt is to be as unique as possible among all instances of hashed passwords, so as to thwart any attempt as parallel attacks (attacking several hashed passwords simultaneously, using precomputed tables such as rainbow tables... are parallel attacks). On distinct systems, several users may share the same login name (there are so many Jones and Smiths out there). Also, a given user may change his password while keeping his name; but even an old password is valuable for an attacker (if only because an old password is often a password that the user will reuse the next time he is being instructed to change his password; also, many users will use identical passwords on other systems).

The recommended way to generate a salt is to use a good random number generator (ideally cryptographically strong RNG) and have it produce a bunch of random bytes. If the salt is long enough (16 bytes or more) then this ensure the required uniqueness with overwhelming probability, and without much hassle (no need to lookup in a database of existing salts, for instance).

We can only hope that this recommended way is also, or will soon become, the "most common" way.

Answer 2

The following is a decent system for salting and hashing passwords. There are a number of points to keep in mind, which is why it looks long. This is a typical example of what one should do when it comes to salt-hashing; I am not going to address what Sun does.

Salts and passwords are best dealt with as raw bytes (byte[], unsigned char*, etc), in case the language one uses deals with text strings in some other form.

Let's generate a new salt using a cryptographically strong pseudo-random number generator to generate the salt. In Ruby, that library is conveniently called securerandom. Most languages also come with a random number generator, but that is not sufficient for a salt.

Let's use SHA256 as our underlying hash algorithm. All hash algorithms have an output size, which is the size in bits of the output of the hash function. All hash algorithms also have a characteristic internal block size, which is not the same as the output size. Let's use a salt as large as the hash algorithm's block size. We do this because this is the largest amount of entropy we can add to the password before hashing it. If we use a larger salt than the block size of the underlying hash algorithm, then HMAC will simply hash the salt first to obtain a smaller salt, reducing its entropy, before mixing it with the password. The block size of SHA256 is 512 bits (= 64 bytes), so let's use a 64-byte salt.

Let's use HMAC-SHA256 instead of SHA256 directly, which does a little bit more work to keep the password safe. We will use the salt as the key parameter to HMAC-SHA256 instead of prepending it to the password. HMAC-SHA256 wraps up SHA256 and does a little extra work to merge the salt with the password.

Finally, the hash algorithms such as SHA-256 are designed to be fast. Whatever our code does overall, it's likely to be spending 1% of its time authenticating users and 99% other stuff. If an attacker gets a copy of the password file, his code is likely to be spending 100% of its time brute-forcing the passwords. So let's make the overall algorithm super-slow: not too slow that it impinges on the rest of our code, but slow enough to discourage the attacker. Let's take a parameter called the work factor (which might be 16), and iterate HMAC-SHA256 2 ^ work-factor times (65536 times in the example). If the work factor were 2, then that would look like

HMAC-SHA256(salt,
  HMAC-SHA256(salt,
    HMAC-SHA256(salt,
      HMAC-SHA256(salt,
        password
      )
    )
  )
)

A good yet simple solution in Ruby:

require "securerandom"
require "openssl"

# method for generating a salt and computing a hashed
# version of a password
def salt_hash(password, work_factor)

  # get raw bytes from the password string; only needed in Ruby >= 1.9
  password = password.force_encoding(Encoding::ASCII_8BIT) if defined?(Encoding)

  # use SHA256 as the underlying hash algorithmn
  hash = OpenSSL::Digest::SHA256.new

  # generate a salt as long as the hash algorithm's block size
  # using a cryptographically strong pseudo-random number generator
  salt = SecureRandom.random_bytes(hash.new.block_length)

  # use HMAC, feeding it two parameters: the salt and the
  # underlying hash; since the underlying hash is SHA256,
  # this turns it into HMAC-SHA256
  hmac = OpenSSL::HMAC.new(salt, hash)

  # iterate running HMAC-SHA256 on the password 2^work-factor
  # times to make this function slow enough to discourage an
  # attacker, but not too slow as to make the service unresponsive
  iterations = 2 ** work_factor
  iterations.times do
    password = hmac.digest(password)
  end

  # return the salt and the hashed password to whoever called
  # this method
  {:salt => salt, :hash => password, :work => work_factor}

end

# how to call the method
salt_hash("seekrit", 16)
# and the output would be
 => {:salt => "raw bytes", :hash => "raw bytes", :work => 16}