Re: Values to use for a salt?

From: Scott Cleven-Mulcahy (scottcm3_at_hotmail.com)
Date: 12/19/03

  • Next message: Brian Hatch: "Re: Values to use for a salt?"
    To: bri@ifokr.org, secprog@securityfocus.com
    Date: Thu, 18 Dec 2003 18:12:42 -0600
    
    

    Brian
    thanks for correcting my overly broad statement that salt must be secret -
    there are definitely situations where salt is not secret. Incidentally,
    Windows 2000 and later (not sure about NTLMv2 under NT4) use a method other
    than salt to provide uniqueness and randomization.

    Still, the point remains that salt can provide two functions: increased
    randomness and uniqueness of a password's hash. Highly random salt, if used
    for all password's, only increases the randomness of a password. It does
    not solve the uniqueness problem - two people with the same password would
    still have the same password hash code. To make the point more relevant,
    consider authentication for a web application.

    My first suggestion is to either purchase or use a well known open source
    package. This stuff is hard and amateurs like myself will probably screw it
    up. Still the need arises, it's good to be familiar the techniques, and
    this is a security programming mailing list.

    In a web application the username and password is often sent to an
    authenticating system, which then hashes it. The client should not be
    trusted to perform this function. The authenticator needs to store a
    mapping of user names to hash codes (storing raw passwords is discouraged).
    In this case, the salt should be highly random, but possibly not unique per
    user. Protection of each user's hash code becomes important to prevent
    birthday attacks, which diminish the effective strength of a hash.

    Since the password hash is normally protected, why would you want to use a
    unique salt? Layered security. In the event that the password hashes
    become exposed, a birthday attack can be used to decrease the effectiveness
    of the hash. The secrecy of the salt will also assist in protecting the
    passwords. The problem is that now you must map username to password hash
    to salt.

    Another possibility would be the following. A mapping table with the hash
    of the username as the table's key, the username, and the user's encrypted
    password hash code. The hash code is encrypted with the authenticator's
    asymmetric public key. The authentication process now looks like this:
    1. Hash the username
    2. Hash the password with salt.
    3. Do a table lookup using the username hash code as the key and retrieve
    the encrypted password hash code
    4. Unencrypt the password hash code using the authenticator's private key
    5. Compare the password hash codes
    6. If the password is being changed, hash the new password, encrypt it with
    the authenticator's public key, and write it into the table.

    Now, if the user database is compromised the attacker needs the
    authentictor's asymmetric private key before they can begin to brute force
    the password hash codes. If the salt value is unique per person then the
    attacker can't compare hash codes to identify identical passwords. Could
    the salt, or HMAC key, be the hash code of the username? It would provide a
    unique salt or HMAC key per user, but I don't know the security impact it
    may have.

    I really need to stress that I am *not* a qualified cryptographer. While I
    think this design can provide secure authentication, someone with more
    expertise would need to critique it. The worst thing to do is to roll your
    own cryptography. Use what's tried and true and tested.

    Hope this helps and that I haven't digressed too much from the original
    topic.

    Scott Mulcahy

    _________________________________________________________________
    Have fun customizing MSN Messenger — learn how here!
    http://www.msnmessenger-download.com/tracking/reach_customize


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

    Relevant Pages

    • Re: Values to use for a salt?
      ... I think you're missing the point of using salt. ... it helps protect against isolated brute force cracks by further ... The importance of using salt is that it protects against hash code ... the secrecy of the key - and account names are not secret. ...
      (SecProg)
    • Re: Custom UsernameTokenManager
      ... sender needs to know the salt. ... encrypt it first with server's public key. ... authentication anyway so you can encrypt and sign future messages. ... This salts the pw and username and encrypts/signs everything so no ...
      (microsoft.public.dotnet.framework.webservices.enhancements)
    • Re: Values to use for a salt?
      ... Yes, for some algorithms, and some applications (like domain ... better methods started) salt is necessary. ... > randomizing a password's hash code, but this is a minor feature. ... > are HMACs (hashed method authentication codes). ...
      (SecProg)
    • RE: Values to use for a salt?
      ... >hash' doesn't make much sense to me. ... generates the same hash code for every password that is "MyPassword". ... The salt value is not supposed to be kept secret, ... I allowed myself to digress from password salt into HMAC. ...
      (SecProg)
    • Re: one way permutation?
      ... with a name, get the salt from the row, do the computation ... In this case, you can use symmetric encryption, in a way that I will ... This isn't absolutely guaranteed against collisions, ... The username and password are encrypted, ...
      (sci.crypt)