saslauthd: support several authentication methods
Dan White
dwhite at olp.net
Thu Dec 17 05:49:06 UTC 2009
On 16/12/09 18:42 +0100, Dmitry Katsubo wrote:
> I simply can't replace user's passwords with plaintext, as I don't know
> them.
You could use the sasl auto_transition option to move from a hashed
password store to a cleartext store as each user authenticates.
> That will be also a potential security hole (if somebody breaks
> into LDAP). I use LDAP to authenticate Samba, FTP, PAM and IMAP users
> and also as address book, so I wouldn't risk a lot and leave saslauthd
> in place.
That's certainly reasonable. Placing cleartext passwords into your auxprop
store (ldap) is a tradeoff between 1) transmitting cleartext passwords over
the network, when using PLAIN/LOGIN but not using SSL, and b) storing
cleartext passwords in your database but disallowing the cleartext
transmission of those passwords over the network (by using DIGEST-MD5
etc.).
I personally see storing cleartext passwords as future proofing my
authentication system and allowing me to perform more sophisticated RADIUS
and Wifi based authentication, and most other forms of authentication I
don't know about yet.
> Of course, my intention is to drop the daemon (which is running with
> root privileges) and switch to ldapdb module, which will be run in the
> context of program that uses SASL, which is potentially better. But
> ldapdb is really tricky to setup. I understand the idea of LDAP
> proxying, but is it possible to introduce 'cmusaslsecretDIGEST-MD5' and
> 'cmusaslsecretCRAM-MD5' attributes for my users and tell ldapdb to use
> MD5 mechanism (not plain text)? Is it what these attributes are aimed
> for?
As far as I know, those attributes are no longer used in Cyrus SASL version
2, but may have been used in version 1.
> Maybe there is some initiative to implement ldapdb in more simple manner
> (1-stage binding)? ... some alternative, which does not go togather with
> SASL package? Or there are some stopping factors, that do not allow such
> module to be implemented (API or security restrictions)?
There is an alternate ldap auxprop plugin found at
http://southbrain.com/south/2008/06/writing-a-cyrus-sasl-ldap-auxp.html
which may be more to your liking. I've only briefly tested it and it is not
included in the sasl source.
--
Dan White
More information about the Pkg-cyrus-sasl2-debian-devel
mailing list