Password Salting Methods

[Michael B Allen]

On 6/2/08, Ken Raeburn <raeburn at mit.edu> wrote:
> On May 29, 2008, at 22:22, Michael B Allen wrote:
>
> > Is there a reference anywhere that outlines the different password
> > salting methods used by different KDCs?
> >
>
>  There are RFCs 3961, 3962, and 4757, which outline how salt strings are
> incorporated in the string-to-key conversion function for each cryptosystem.
>  RC4 ignores it, the others actually use it.
>
>  How the salt string is determined is separate.
>
>  According to RFC 4120, the default salt string is generated by joining the
> realm and principal components without separators.  If another string is to
> be used, it must be indicated by some sort of preauth data like ETYPE-INFO2.
>
>  The MIT KDC has support for some specific variations on salt strings, such
> as using only the realm, only the principal name without the realm, "v4"
> (i.e., no salt string at all, or rather an empty string), and "special" (a
> string stored in the principal record in the database with the key).
>
>  Using the principal name as a salt string makes it more difficult for an
> attacker to precompute a dictionary of keys derived from a dictionary of
> pass phrases.  Instead of generating a single complete dictionary, the
> attacker must pick a principal name (more to the point, a specific salt
> string) to use in the dictionary generation.  Or, the attacker could
> multiply the pass phrase dictionary size by a set of principal names (salt
> strings) to be attacked, which increases the work to be done by that
> multiplier.
>
>  Someday I'd like to see us have a flag in the database to indicate that
> random salt strings should be generated at every password change.  Then even
> if a user keeps picking passwords that are in the attacker's dictionary, a
> dictionary built based on one salt string will be useless as soon as the
> password is changed.  It probably would help to make them long, with
> comparable random bits to the key size itself, rather than a set of short
> alphanumeric strings as usernames often are.  Then the distribution of
> password-generated keys, over a large set of users and password changes, is
> spread out over the entire key space.  Someday....
>
>  Anyways, the enctype specification for the MIT KDC also indicates the salt
> type to use for each, when creating principal entries or changing passwords.
>
>
> > AFAICT AD w/ RC4 doesn't actually use a salt. Heimdal seems to just
> > use the realm and principal name concatenated together without any
> > separators.
> >
>
>  Right, that's the RC4 behavior, and the default salt as specified in the
> protocol.
>
>
> > What does MIT do?
> >
>
>  As above...
>
>
> > What does Windows 2008 w/ AES use?
> > Windows 2000?
> >
>
>  I can't tell you for sure offhand, but I would assume it probably either
> uses the default per RFC 4120, or sends ETYPE-INFO(2) to indicate no salt
> string is used.
>
>
> > Do the salt values change depending on the enctype?
> >
>
>  The default is protocol-wide.  However, the database could store different
> salt strings for different encryption types.
>
>  I'd have to think a bit to figure out if it's valid for the database to
> have different salts for a single encryption type, with the KDC randomly
> choosing between them.  I don't know if that would break any interesting
> assumptions that client software might reasonably make.
>
>
> > I'm interested in knowing to what degree salts can be predicted given
> > only the information a client preparing to issue an AS-REQ would have.
> >
>
>  Obviously you can guess that it'll use the default...  You could also cache
> the value from the previous time.

Excellent information Ken. This will help a lot.

Thanks,
Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/