Kerberos and "account lockout" technology

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Kerberos and "account lockout" technology

Martin Rex
Forgive me a question that is not on the charter of this WG,
but I got a customer inquiry on a Kerberos-related issue today and
this is the only Kerberos discussion forum to which I'm subscribed.

The customer is worried, because *our* software visualizes
the servers kerberos principal name -- and as they have
an "account lockout" feature active on their KDC for a small
number of failed authentication attempts.

With the knowledge of the servers kerberos principal name,
an attacker could easily mount a denial-of-service attack
on our (distributed) server by simply performing the necessary
small number of invalid login attempts and lock out the servers
account this way, so that the server will no longer be able
to authenticate to the KDC and acquire TGTs...
(actually, our server will not even start because the os-integrated
 logon fails when the account is locked out...)


IMHO, given an modern encryption type with a decent keysize (AES-256),
account lockout shouldn't be necessary for service acconts with strong
random keys, but, unfortunately, not all Kerberos implementations are
born equal and the customers Kerberos implementation does not offer
strong random keys for service accounts...


-Martin
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos and "account lockout" technology

Jeffrey Hutzelman


On Thursday, December 01, 2005 12:02:49 AM +2500 Martin Rex
<[hidden email]> wrote:

> Forgive me a question that is not on the charter of this WG,
> but I got a customer inquiry on a Kerberos-related issue today and
> this is the only Kerberos discussion forum to which I'm subscribed.

Well, the "right" forum for this is probably comp.protocols.kerberos,
which also goes by the name [hidden email].  That said, I think the
question is close enough to on-topic for a few messages.


> With the knowledge of the servers kerberos principal name,
> an attacker could easily mount a denial-of-service attack
> on our (distributed) server by simply performing the necessary
> small number of invalid login attempts and lock out the servers
> account this way, so that the server will no longer be able
> to authenticate to the KDC and acquire TGTs...
> (actually, our server will not even start because the os-integrated
>  logon fails when the account is locked out...)

Yup, that's a problem.


> IMHO, given an modern encryption type with a decent keysize (AES-256),
> account lockout shouldn't be necessary for service acconts with strong
> random keys, but, unfortunately, not all Kerberos implementations are
> born equal and the customers Kerberos implementation does not offer
> strong random keys for service accounts...

I agree.  Personally, I prefer using strong randomly-generated keys for all
principals whenever possible.  The only time a weak "password" should be
needed is when a human will have to enter it from memory, such as a user's
login password.  At our site, we use randomly-generated keys not only for
services but also for daemons and other entities that will act as clients,
but which always use a stored key rather than one typed from memory by a
person.

That said, I don't think the "everything has a password" model used by some
implementations is insurmountable.  For example, my understanding is that
Windows computer accounts use long, randomly-generated passwords.  I should
think that using a similar approach for your application, combined with a
suitably strong enctype, would provide sufficient security to allow
disabling the password-lockout feature for that account.



-- Jeff