Greg Hudson <ghud...@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 (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
