New "feature" for Kerberos?
John Hascall
john at iastate.edu
Sat Nov 9 10:59:00 EST 2002
The University Auditors seem to be chomping at the bit for
some sort of N-strikes-and-you're-out feature. In my opinion,
the only way this makes any sense is if it auto-re-enables
after some period of time (I sure don't want to do a whole
bunch by hand).
Before I start:
- is this stupid and I should resist harder?
- is anybody else working on something like this?
- does my plan (below) seem a reasonable approach?
- what are the odds of getting such a mod into the
std dist so I don't have to keep refitting it?
Thanks,
John
------------------ my proposed approach ---------------------
So, I'm thinking this would take two new policy fields:
n_strikes, an integer count
strike_time, a delta time of how long before re-enable
and one new principal field:
re_enable_time
and work something like this:
if (princ.re_enable_time != 0) {
if (princ.re_enable_time > now) {
return SORRY;
} else {
princ.re_enable_time = 0;
}
}
if (checkPassword(princ, pass) == OK) {
princ.failed_cnt = 0;
} else {
princ.failed_cnt++;
if (policy.n_strikes) {
if ((princ.failed_cnt % policy.n_strikes) == 0) {
princ.re_enable_time = now + policy.strike_time;
}
}
return SORRY;
}
An alternative would be to not add princ.re_enable_time
but to impute it:
if (princ.failed_cnt && policy.n_strikes) {
if ((princ.failed_cnt % policy.n_strikes) == 0) {
if ((princ.last_failed + policy.strike_time) > now) {
return SORRY;
}
}
}
if (checkPassword(princ, pass) == OK) {
princ.failed_cnt = 0;
} else {
princ.failed_cnt++;
princ.last_failed = now;
return SORRY;
}
Random thoughts:
+ Obviously, this requires the REQUIRES_PRE_AUTH attribute,
and ./configure --with-kdc-kdb-update
+ Not changing the principal structure has its appeal, of course.
+ But having princ.re_enable_time would allow kadmin's getprinc to
display it easily, and modprinc to reset it (early) manually.
+ I suppose that some value of policy.strike_time (0, -1, 0x7fffffff,
something) should mean "forever, until reset manually".
John
More information about the krbdev
mailing list