PFiver via SASL wrote: > Got it.... thank you! > > I was finally able to get cyrus-imapd to talk to the ldap as well, by removing the "-hashed" suffix. > > I am wondering, what to do now. For one thing, hashed LDAP passwords seem to be supported in saslauthd: > https://github.com/cyrusimap/cyrus-sasl/blob/master/saslauthd/lak.c#L128 > > I am not willing to story pain passwords in the ldap (and use "auxprop" with "ldapdb" as is), but I am tempted to attempt to port that part over to the > sasl-ldapdb module. > > The first option would certainly be easier. But the second more fun, maybe. :-) > > But what are - hypothetically - the chances of getting that code - assuming it would be a few dozen lines in, say plugins/ldapdb.ch and maybe re-using parts > from lak.c - accepted in cyrus-sasl? > > Would some of the original developers and/or current maintainers of the code in question be willing to assist in helping to collect all the information > required and drafting a design for a solution? > > - plugins/ldapdb.ch -> e.g. Howard Chu, Ken Murchison ? > - saslauthd/lak.c -> e.g. Igor Brezac, Rob Siemborski ? I am a current maintainer. My attention has been on other projects, had no idea the auxprop API had evolved to support hashed passwords. Sure, we can probably add that in. Though TBH, my purpose in writing ldapdb in the first place was to eliminate simple-password based login mechanisms. IMO it is more of a liability to have them traversing the wire than to have them stored inside OpenLDAP. Which is why I was only interested in supporting mechs like DIGEST-MD5 (and presumably now SCRAM). Be sure you understand what your threat model and actual threat environment is. When you support server-side hashed passwords that necessarily means your client is sending plaintext passwords to be validated by the server. IMO this is the worse risk. With the current ldapdb support, clients only send randomly generated nonces to the server, so the password itself never traverses the network. In general one can expect that clients are connecting over random untrusted networks, making transmitted passwords more of an easy target. And we assume that the sysadmin is competent enough to secure communication between the SASL service and the LDAP service. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ------------------------------------------ Cyrus: SASL Permalink: https://cyrus.topicbox.com/groups/sasl/T2c60ca246b64197b-M9c7eb64c8f16faa8c1963fc1 Delivery options: https://cyrus.topicbox.com/groups/sasl/subscription
