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 |
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 |
Free forum by Nabble | Edit this page |