3 messages in net.sourceforge.lists.courier-usersRe: CRAM-SHA1 [UNKNOWN]sucks.  was:...
FromSent OnAttachments
Matt PavlovichFeb 20, 2003 12:58 pm 
Matt PavlovichFeb 21, 2003 7:45 am 
Sam VarshavchikFeb 21, 2003 2:39 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: CRAM-SHA1 [UNKNOWN]sucks.  was: [courier-users] ESMTP Auth and LDAP problemsActions...
From:Sam Varshavchik (mrs@courier-mta.com)
Date:Feb 21, 2003 2:39:45 pm
List:net.sourceforge.lists.courier-users

Matt Pavlovich writes:

Well, 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.

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.

So CRAM hash methods could be supported with hashed passwords stored in the directory? I would definitely like to submit this as a feature request if it is technically possible.

Well, its technically possible, but this is just a custom implementation hack for userdb. There is no officially defined format for such a partially-computed hash field, in LDAP. You've got {MD5}, you've also got {SHA1}, you've got a few other things as well. You do not have anything that understands what {HALF-BAKED-HMAC-SHA1} is.