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