> From: Brian Candler <[EMAIL PROTECTED]> > > On Thu, Feb 20, 2003 at 12:15:17AM -0800, John Rudd wrote: > > Because the KDC knows the master key, and the master key is what is > > used to _encrypt_the_database_. If you want to access the key database > > directly, YOU have to know the master key pass-phrase too. You cannot > > just look in the database using the appropriate database tools (for > > whatever database engine you're using), because the entries are all > > encrypted. If you (the kerberos administrator) forget the master key > > pass-phrase, you're kinda screwed. > > This doesn't change the original point: you are not storing a one-way hash > of your Kerberos secrets, just obscuring them in a way which can be reversed > at the time when you need to use them.
That may have been the original point, but that wasn't how it was stated. It was stated as "the server has to store the passwords in plain text, or the password has to go across the wire in the clear". Kerberos does neither of those. And, I'm still pretty sure the server never directly knows your password in the first place (it stores something that you cannot use without having the the right password, but it doesn't have your password). > The same method works equally well for a SASL database of plaintext > passwords. i.e. you can encrypt the whole lot with a symmetric cipher. When > you need to authenticate someone, you decrypt the relevant password and run > in through the CRAM algorithm. Yes, but, wasn't the original complaint that "this isn't being done", not that "it cannot be done"? I didn't offer kerberos as "the only solution", I offered it as a counter-example to the statement that the password has to be in the clear somewhere. ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
