pre-authentication attacks

[Russ Allbery]

Greg Hudson <ghudson at mit.edu> writes:

> * The AES enctypes have an intentionally expensive string-to-key
> function, making brute-force password attacks more expensive by a
> significant but constant factor.

The one caveat I'll add to this, though, is that "intentionally expensive"
changes over time.  Current crypto best practices would use about 3x as
many rounds as the AES enctype specifies as the default, and would use
per-principal salt.

The Kerberos protocol permits the server to tell the client both the salt
and the rounds, so you could dynamically adjust the rounds and use
per-principal salt within the protocol (or, even better, randomize the
salt on every password change).  However, I don't know if anyone
implements the tools required to manage this properly, or if typical
clients would cope.

> * The RC4 enctype doesn't use the salt, making brute-force password
> attacks easier since a string-to-key table can be constructed which
> applies to all principals.

Also, the hash function is relatively trivial, so even without a rainbow
table a brute force attack is much easier.

> * FAST prevents brute-force password attacks as long as the attacker
> does not know the armor ticket key.

...but of course the attacker can still attempt to brute-force the armor
ticket key, which is why it's important for that key to be completely
random to force the attacker to search the full key space, or to negotiate
it using something like PKINIT.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>