Re: Values to use for a salt?

From: Marian Ion (marian.ion_at_e-licitatie.ro)
Date: 12/22/03

  • Next message: Ton Geurts: "RE: Values to use for a salt?" 
    To: "Scott Cleven-Mulcahy" <scottcm3@hotmail.com>, <secprog@securityfocus.com>
Date: Mon, 22 Dec 2003 12:10:49 +0200

        Yes, for some algorithms, and some applications (like domain
    authentication, for example - but already the implementation of newer and
    better methods started) salt is necessary. But maybe it's a matter of
    algorithm, maybe the logic and mathematic behind the name is weak (and i
    think this is the case with LM and NTLM v1). And, for NTLM 2, maybe the
    secured channel was the best improvement (128 bits is still weak ...).
        Currently, when talking about 1024, 2048, 4096, etc bits for a password,
    when talking about Idea, AES, and many other very good algorithm, I consider
    salt as redundant, because there is no -knowable, at least- way to brute
    force or somehow engineer these kind of passwords (again, I'm not talking
    about weak algorithms, like, I don't know, RC x, DES, 3DES, or others).
        I think (and I'm aware that I might prove wrong) that salt is for weak
    algorithms and weak passwords, set by regular users, not by a security
    administrator. But I would not let regular users set their own passwords,
    and use them for years ...

    Regards,
    Marian

    ----- Original Message -----
    From: "Scott Cleven-Mulcahy" <scottcm3@hotmail.com>
    To: <secprog@securityfocus.com>
    Cc: <marian.ion@e-licitatie.ro>
    Sent: Thursday, December 18, 2003 5:57 AM
    Subject: Re: Values to use for a salt?

    > I think you're missing the point of using salt.
    >
    > Yes, it helps protect against isolated brute force cracks by further
    > randomizing a password's hash code, but this is a minor feature. Using
    the
    > extended ASCII set in a password serve's the same purpose. Regardless, I
    > certainly wouldn't rely upon salt to improve the quality of an
    individual's
    > password.
    >
    > The importance of using salt is that it protects against hash code
    > comparing. Ideally, each password is hashed with a different salt value.
    > When this is done, the hash code of identical passwords is not identical.
    > One of the problems with LM and NTLM v1 passwords is salt wasn't used. As
    a
    > result, once you found one password you knew the password of anyone else
    > that has the same hash code.
    >
    > There are other methods that can protect against hash code comparison, but
    > using larger character sets in a password is not one of them.
    >
    > 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.
    >
    > Depending on the length of time the hash code had to stand up and the
    value
    > of the information you're protecting, you could use the account name as
    > *part* of the key. A common technique is to take some data, hash it, drop
    > some of the bits and use the remainder as the key. In a highly simplified
    > example you could use Hash(account name + MAC address + IP address + Date
    +
    > Time to the nearest minute), drop enough bits off the end to make it the
    > right size and that could be the key. Depending on the difficulty in
    > regenerating the key it may stand up if the key is changed frequently
    and/or
    > the data holds little or no value in a short amount of time.
    >
    > In order to validate the hash code, the validating system computes all
    hash
    > values (there are multiple valid keys) for each minute within a window of
    > time. If any of the codes match the hash code is considered valid. This
    is
    > basically what Kerberos does (and is why authentication doesn't work in a
    > Windows 2000+ network if the time isn't synchronized within 5 minutes).
    >
    > Hope this helps,
    > Scott Mulcahy
    >
    > -----Original Message-----
    > From: Marian Ion [mailto:marian.ion@e-licitatie.ro]
    > Sent: Wednesday, December 17, 2003 3:01 AM
    > To: CraigSecurity@blazemail.com; secprog@securityfocus.com
    > Subject: Re: Values to use for a salt?
    >
    >
    > Hi all,
    >
    > Don't you think using extendedASCII set will dramatically increase the
    > performance of any algorithm currently in use? Imagine what a pass like
    > "|¤W-|[V.|1D-|`â-|Ë3-|%-|F0-| " means for a cracker: (selected from
    line
    > 22 (I think...) from regedit.exe). Imagine using Unicode characters for
    keys
    > .....
    > Will you still need salt and others?
    >
    > Marian Ion
    >
    > _________________________________________________________________
    > Enjoy the holiday season with great tips from MSN.
    > http://special.msn.com/network/happyholidays.armx
    >

  • Next message: Ton Geurts: "RE: Values to use for a salt?"

    Relevant Pages

    • Re: Values to use for a salt?
      ... there are definitely situations where salt is not secret. ... Protection of each user's hash code becomes important to prevent ... The problem is that now you must map username to password hash ... The authentication process now looks like this: ...
      (SecProg)
    • Re: Crypt SALT value
      ... Gerrit Hulleman wrote: ... I am no expert on encryption ... > algorithms, but the salt is like the key, without the key it should be ...
      (comp.lang.perl.modules)
    • Re: Crypt SALT value
      ... > algorithms, but the salt is like the key, without the key it should be ... The SALT in included in the resulting cryted string, ... entered password was the same, ...
      (comp.lang.perl.modules)
    • 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: [IMPORTANT] Kerberos Issue : Pre Authentication failed (Error Code 24) with SAM account / No err
      ... Yes, we had a similar lamely done pre-auth issue with the java libs, ... I'm a Business Intelligence consultant working on Business Objects ... The Kerberos authentication is done through a JVM and we can ... any pre-auth parameters including the salt assuming it knew the salt. ...
      (comp.protocols.kerberos)
    • Quantcast