Matt Pavlovich writes:
No, no. Do the same challenge/response mechanism, but instead of usingWell, one final bootnote is that it is actually possible to do something like that with the existing CRAM-hash method. And, in fact, the authuserdb module does exactly that.
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.
Without getting into the gory details, the computation of the final CRAM-hash value begins with the cleartext password. It is possible to begin the first step of computing the hash, and save the intermediate hash code. Then finish the computation when the client replies to the challenge.
The saved data is, indeed, a one-way hash of the cleartext password. Now, anyone who recovers the intermediate hash will be able to succesfully authenticate, but without having the original cleartext password in hand. The gory details of how to implement that is specified in the relevant RFCs, for those who are interested.
So, the only value-added benefit of using this approach is where the same cleartext password is used someplace else, this you won't get that. You'll still be able to access the account, but won't be able to know the password for the other resource.
-------------------------------------------------------
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
