On 08/05/2016 09:51 AM, Jerry Shipman wrote: > I am trying to do something like this: > - I identify a user whose password is known to an attacker by some other > process > - I scramble the user's password and tell him he that needs to reset it by > some outside process (e.g. a trip to the helpdesk with his ID) > - When the user resets his password, then he can authenticate again. > - But, there is a little gap... after I scramble the password, the attacker > can no longer get new TGTs... but he might still have an old TGT for a few > hours until it expires, which he can use to get new service tickets. Is there > a way to prevent that? (He could also already have some active service > tickets, but I don't think there is anything I can do about that.)
Currently there is no way to prevent that. The TGS code path in the KDC doesn't perform any policy checks on the client principal entry, so even if the client principal is disabled, the KDC will continue issuing service tickets for existing TGTs until they expire. I think the historical viewpoint was that, because the attacker could have acquired service tickets at the time the tickets were stolen, there isn't much point in going to extra effort to make it possible to close the barn door after the horse has escaped. (Also, if the client principal is in another realm, the TGS server doesn't usually have access to its database entry.) We have considered reversing this position at times, but haven't implemented any changes to date. For this specific scenario, we would need more than to examine the client principal entry for the usual policy checks; as you surmised, we would need a way (perhaps a principal flag) to express that old kvnos are invalid for this principal entry. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos