[4613] in Kerberos
Re: Brute-force decryption (was: Should I restrict 'kinit' access)
daemon@ATHENA.MIT.EDU (Andrew Pochinsky)
Mon Feb 13 19:45:46 1995
To: kerberos@MIT.EDU
Date: 14 Feb 1995 00:29:29 GMT
From: pochinsk@ctpa04.mit.edu (Andrew Pochinsky)
In article <3hollb$muh@senator-bedfellow.MIT.EDU> kdo@marie.mit.edu (Ken Olum) writes:
> In article <MARC.95Feb8200043@dun-dun-noodles.cam.ov.com> marc@cam.ov.com (Marc Horowitz) writes:
> >>> Is it a security risk to let users have access to the 'kinit' command?
> >>> Can't they sit and hammer it all day trying to break someone else's
> >>> password by brute force?
> >
> >This problem can be alleviated with kerberos v5's preauthentication
> >feature, but such an environment would still be susceptible to
> >snooping of the initial ticket and offline attacks on that.
>
> Kerberos could be extended to prevent brute-force attacks of this
> sort. For example, instead of your initial ticket, the server could
> generate a random integer and send it to you. You decrypt it with
> your password and send it back. If it's right, then you get your
> actual ticket. If it's wrong, then the server increments the number
> of wrong guesses at your password, and if you guess too many times it
> freezes your account.
>
The problem with this particular approach is that the server should
keep the random number it generated untill the client sent it
back. Hence, the server is not stateless any more, which invalidates
one of the design requirements of Kerberos.
I think that the problem of the brute force cracking exists in
Kerberos because it's possible to check the password without server
knowning about such an attempt. Suppose one knows the principal's
name. Now if the intruder asks the authentication server for the
initial ticket. The intruder could try as many wild guesses on
user's password as he wants to decypher the ticket -- he does not need
to send any request to the authentication server to check if his guess
is correct.
Andrew
