Re: auxprop pwcheck with sasl ldapdb and openldap backend not working

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:
> 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/ 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/ -> 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. 
  Director, Highland Sun
  Chief Architect, OpenLDAP

Cyrus: SASL
Delivery options:

[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux