RE: Values to use for a salt?

From: Mark Burnett (mb_at_xato.net)
Date: 12/19/03

  • Next message: Brian Hatch: "Re: Values to use for a salt?" 
    To: <secprog@securityfocus.com>
Date: Fri, 19 Dec 2003 10:01:01 -0700

    I have watched this thread with some interest and I wanted to clear up
    some misunderstandings of salt, hashes, and HMACs (and maybe also plug
    my upcoming book "Hacking the Code" from which this is derived):

    First of all, the purpose of a salt is to provide randomness for
    hashes so that the same password doesn't always produce the same hash,
    forcing the attacker to compute the hash and preventing pre-computed
    hash attacks or known-plaintext attacks. Therefore a salt must meet
    these two requirements:
    1. The salt must produce enough hashes for any given password to
    prevent the attacker using a dictionary of pre-computed hashes.
    2. The salt should be unique for each user with few collisions.

    Deriving the salt from the username does produce multiple hashes for
    any given password and does provide uniqueness for each user within a
    single system but not across multiple systems. Therefore someone could
    build pre-computed dictionaries for common users such as root or
    administrator. You should not derive the salt from the username.

    Deriving the salt from the password does not produce a unique hash
    because a password salted with itself can still only produce one
    possible hash. You should not derive the salt from the password.

    A large random number for the salt provides a huge number of possible
    hashes for every password and provides enough key space to ensure
    uniqueness, even across multiple systems. When creating salts for
    storing hashes for authentication purposes the generally accepted
    method is to generate a large random number and there is little reason
    to come up with a new scheme for creating salts.

    Note that there is no requirement to keep the salt secret because
    knowing the salt does not gain the attacker the benefit of not
    computing hashes. We assume here that the hashes themselves are at
    least somewhat protected. Generally if the attacker has access to the
    hashes the attacker also can gain access to the salts no matter what
    scheme you use. Therefore, storing the salt along with the hashes is
    acceptable and still meets the requirements of a salt.

    Now there are situations where you must transmit a hash across an
    insecure medium and therefore risk exposing the hashes to attackers.
    In these cases you use a keyed hash, or HMAC, which is technically the
    same as a salt but in practice is different because you must now
    protect the key itself rather than the hash.

    With a key you have further requirements:
    1. You must use a strong random number generator for the key.
    2. The key must utilize a large enough key space to prevent a brute
    force attack.
    3. The key must be protected as a secret.

    So it is important to distinguish between salts used for storing
    password hashes and keys used for transmitting hashes across an
    insecure medium. A salt adds randomness to a hash and does not need to
    be kept secret and can be stored with the hash. A key protects a hash
    and should always be kept secret.

    Mark Burnett

  • Next message: Brian Hatch: "Re: Values to use for a salt?"

    Relevant Pages

    • Re: Importance of salt
      ... That is the problem with using one-way hash ... The salt is used on ... The attacker really couldn't use his ... > even knows the correct iteration count used. ...
      (microsoft.public.dotnet.security)
    • Re: Newbie - Is this Reasonable?
      ... PKCS5v2 to generate your IVs and Keys. ... I use PKCS5v2 to generate the hash of each user's login ... So you use PKCS5v2 to generate a key hash from a salt and ... themselves to off-line analysis, so the attacker can ...
      (sci.crypt)
    • Re: Hashed password secure?
      ... ]> The stupidly written BSD md5 based unix password function simply runs the ... ]> hash 1000 times to try to slow it down. ... ]impossible for some attacker to create a dictionary of hashes ... As machines get faster, the salt will get more bits, so it ...
      (sci.crypt)
    • Re: password salting
      ... For attacker, I assume pre-computed hash tables are just not that helpful ... You can only add so many iterations to ... |> If you have the salt and the hash, the salt does not make attacking ...
      (microsoft.public.dotnet.security)
    • Re: Hashed password secure?
      ... > Consider the way that a typical password hash attack program works. ... > the salt, and then it hashes the dictionary once for each unique salt value ... So the attacker has to hash the dictionary 2^16 ... want to not store his dictionaries, he'd have to try on average half his ...
      (sci.crypt)