New "feature" for Kerberos?

[John Hascall]

> > 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