> On Thu, 2003-02-20 at 08:52, Matt Pavlovich wrote: > > No, no. Do the same challenge/response mechanism, but instead of using > > the clear password as the shared secret, use the SHA1 (or other) hash of > > the password. > ... > > The server never knows the clear password, and any man in the middle > > would need to know the hash of the password in order to break it.. which > > is the equal of needing to know the password in the current CRAM-* > > methods.. (maybe stronger as you may get the 'triple des effect'). > > You just worked out that storing the hash of the password in that case > is functionally the same as storing the original plain text password. > The security risk involved with storing the plain text password is that > instead of an attacker grabbing the password from the transmission, he > can get it from the server if he compromises that (The question is: > which is more secure, your server or your network?). If the server > stores and uses a hash of the password, an attacker can still steal the > hash and use that for authentication.
I am not trying to solve the "ubber computer security problem". As most know, computer security really comes down to physical security and interaction b/w people vs. some really bitching algorithm. Currently we are faced with bad security models with anything CRAM-* given that the server has to store a clear password, which we can all agree on is not as desirable as storing a crypt text password. That password may be used for other services, where the crypt version is not the functional equivilent as the hashed version. The goal is to create something that sucks less than what we have now and move forward from there. If we can improve the security of current methods, then we improve the security of the overall system. Taking the challenge/response from CRAM-* but using a hashed version of the password is an improvement over having to use clear passwords on both sides. This could also improve the problem of locally storing passwords for e-mail clients. (Again, the hash becomes the functional equivilent, but if that password is used for other services, we have improved our overall standing). Getting the majority of E-Mail clients and servers to support a new method seems to be a greater challenge than just improving the model, so if anyone has an idea on how to do that, speak up. ;) -- Matt Pavlovich <[EMAIL PROTECTED]> Allegiance Telecom, Inc. ------------------------------------------------------- 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
