>Well lets look at the situation where all they got was the KDB. I don't >think the off-line cracking is really needed. Since they have the hash >of the password they could just kinit using that as the shared key. I >don't think the kinit tools as they are now could do it but it could be >done with some modifications. So I don't think that they need to be able >to derive the actual password. So in other words if someone has the KDB >(and not root on the server) then they could impersonate any one that >authenticates against that KDC.
I suppose it depends on your actual use of Kerberos. If you're the sort of person who uses Kerberos _passwords_ a lot into things like web forms, then just knowing the key will not be that useful to you to attack those things (because those web forms won't accept the raw key). If you use native Kerberos authentication, then it wouldn't be too hard to use the native tools to place those keys into a keytab and just use kinit to authenticate as those users. However ... worse than that, all someone REALLY needs is the TGS key and they could impersonate any user (even ones that might not exist, like, for instance, "root"). I'm not sure the native tools have that capability, but I am sure there are programs floating around that let you do that. The same goes for service keys (although an attacker could only impersonate any user to whatever service key they have). Basically, if you're in that scenario, EVERY key in the database needs to be rekeyed. --Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
