Re: Values to use for a salt?

From: Brian Hatch (bri_at_ifokr.org)
Date: 12/18/03

  • Next message: Kenneth Buchanan: "Hash salting -- digression" 
    Date: Thu, 18 Dec 2003 12:09:09 -0800
To: Scott Cleven-Mulcahy <scottcm3@hotmail.com>

    > On a related note, earlier someone asked if it was advisable to use the
    > user's account name as the salt value. The answer is no. To be effective,
    > the salt value should be kept secret. In essence, what we're talking about
    > are HMACs (hashed method authentication codes). HMACs are only as good as
    > the secrecy of the key - and account names are not secret.

    Salts should be completely random. Always.

    Should salts be secret? Maybe it depends on the system, but if
    you take unix password hashing, salts are *NEVER* secret:

            $ perl -e 'print crypt( "my pass", "salt" ), "\n"'
            saTFlq8BYSMRY

    In this case we're using a DES-style hash, with a salt 'salt'.
    Salts for this form of crypt are actually only two characters
    long, so the salt is really just 'sa'.

    Note the first two letters of the resulting hash: 'sa'.
    The salt is stored as part of the result.

    To check, a password, you'd use this:

            # the hashed password, as snagged from /etc/shadow, etc
            $hash='saTFlq8BYSMRY';

            # the password to try, as snagged from the user
            $pass="my pass";

            if ( crypt($pass,$hash) eq $hash ) {
                    print "Yes, they're the same\n"
            }

    There's no way to verify a password unless you know the salt,
    which is always the first two characters of the hashed password
    (hense using '$hash' as the second argument to crypt above.)

    The salt needs to be stored somewhere, and needs to be available
    to the password checking routine. It doesn't necessarily need
    to be in the hash result itself, but it needs to be somewhere. 

    --
Brian Hatch                  "The secret of our marriage's
   Systems and                success, Londo, is our lack of
   Security Engineer          communication.  You've jeopardised
http://www.ifokr.org/bri/     that success and I would know why."
Every message PGP signed

    • application/pgp-signature attachment: stored
  • Next message: Kenneth Buchanan: "Hash salting -- digression"

    Relevant Pages

    • Re: Best Way To Randomize/Salt A Text String Before SHA256?
      ... In principle, as long as your hash function is secure, all you need to ... If the user can store a fairly long secret salt, the ... since brute force attacks become infeasible. ...
      (sci.crypt)
    • Re: Using encrypted dB connection string
      ... the hash you've stored in the database. ... The salt is not a secret - it's just random bits that are concatenated ... pre-computed password hashes will not work. ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: Best Way To Randomize/Salt A Text String Before SHA256?
      ... secret, it's safe. ... while a computationally unbounded attacker can't get your ... For information-theoretic security, ... Let C = Fbe a commitment to message m with random salt s. ...
      (sci.crypt)
    • Approve Account. Security. Advice is welcome.
      ... URL to approve its account: ... Then hash that string ... ... Or maybe have a predefined Salt just for create this keys? ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Unique Key vs. Initialization Vector ?
      ... >Consider a block cipher in CBC or CFB mode. ... This salt would use information already ... What you're doing is using salt plus the secret ... my suggestion to you is that instead of ...
      (sci.crypt)