New "feature" for Kerberos?
John Hascall
john at iastate.edu
Mon Nov 11 10:14:00 EST 2002
> > The University Auditors seem to be chomping at the bit for
> > some sort of N-strikes-and-you're-out feature.
> > Before I start:
> > - is this stupid and I should resist harder?
> It only makes sense if you can see an appreciable chance that
> passwords can be guessed. If you impose a length & diversity
> requirement and the cracklib dictionary test, and you require
> password changes regularly, this risk is minimal. (Only someone
> who shoulder-surfed most of a password would be able to guess.
We have length & diversity requirements, and we do a
limited amount of dictionary testing. However, making
these tougher would, I think be less well received.
Once I found this:
if (client.fail_auth_count < KRB5_MAX_FAIL_COUNT) {
client.fail_auth_count = client.fail_auth_count + 1;
if (client.fail_auth_count == KRB5_MAX_FAIL_COUNT) {
client.attributes |= KRB5_KDB_DISALLOW_ALL_TIX;
}
}
I was not concerned about a brute force attach (if I'm
reading the code correctly, KRB5_MAX_FAIL_COUNT is 5).
Ignoring the auditors, *my* real concern is some smartass
could come in 5 minutes before finals start some morning
and do 5 attempts on every principal we have and lock them
all out until we figured it out and corrected it.
[40,000 principals / 1,000 (per sec) * 5 tries = 200 seconds]
So, I'd like to have this go away automatically.
The "nicest" way would be to have the variables
reside in the policy structure, I think. Obviously,
it would be a pretty quick hack to hard code a
fixed timed reset in the server.
John
More information about the krbdev
mailing list