On Wed, Oct 7, 2015 at 10:07 PM, Edward Ned Harvey (lopser) < [email protected]> wrote:
> Notice that the KDC had the client's password to encrypt the TGT, and then > the client decrypts using the password. After the client has received the > TGT, it's able to authenticate to other servers with no *further* password > exposure, but the password was exposed to the KDC. You've made several assumptions about what is going on, and at least one is incorrect. For starters, the KDC already *has* the user's password; that's what the KDC database has in it, encrypted with the realm master key. (kpasswdd does send a form of the password to the KDC on password change, but it is using an encrypted channel. Likewise kadmin. Note that neither is actually part of Kerberos and neither is standardized --- there is SEAM but I think only Solaris uses it. heimdal and MIT can't use each others' kadmin or [I think] kpasswd protocols.) The whole point of Kerberos is not to let the actual password over the wire or even outside the process handling it. http://web.mit.edu/kerberos/dialogue.html -- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
