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 client knows the clear text password. A server could have a password in any number of formats. Clear, crypt+/-MD5, SHA1, SSHA, etc... In a perfect world, clients would be smart enough to work with whatever hash the server is requesting. The server advertises supported extensions.. let's call it 'NO-SUCK-CRAM'. If the server supports 'NO-SUCK-CRAM', then the server issues the challenge, along with an indicator as to what hashing scheme to use. The client then hashes the clear password to match what the server knows, then hashes against the challenge and replies with the 'hash of hash'. The server then can do a simple compare of the hashed strings. 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'). Matt Pavlovich On Wed, 2003-02-19 at 18:09, Gordon Messmer wrote: > On Wed, 2003-02-19 at 14:21, Matt Pavlovich wrote: > > > It sounds as if CRAM-SHA1 does not send a derivation of a SHA1 hash of > > the password and request a valid response from the server replying with > > a derivation of the same SHA1 hash. > > Right. If it did that, then the SHA1 hash that the client sent to the > server would always be the same. If the hash is always the same, then > it's "plain text". It can be sniffed and re-used, and there's no > benefit to the hashing. > -- 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
