This is a discussion on Re: Password Salting Methods - Kerberos ; 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 ...
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
> AFAICT AD w/ RC4 doesn't actually use a salt. Heimdal seems to just
> use the realm and principal name concatenated together without any
Right, that's the RC4 behavior, and the default salt as specified in
> What does MIT do?
> 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.