Re: saslauthd -a ldap ( possible BO / bug with long userpassword strings ? )


Subject: Re: saslauthd -a ldap ( possible BO / bug with long userpassword strings ? )
From: Igor Brezac (igor at ipass dot net)
Date: Wed Apr 16 2003 - 15:11:01 EDT


On Wed, 16 Apr 2003, Edward Rudd wrote:

> well, i mean it'll work with custom.. but the more secure method would
> be to use bind. Having saslauthd search for the DN of the user, then
> bind as that user to the LDAP. then you can use ANY password encryption
> scheme on the LDAP as saslauthd doesn't need to know how it's encrypted.

This is incorrect. bind would be at best equally secure (really
insecure), but in most cases less secure. Bind transmits passwords in
clear over the network no matter what hash you use, custom transfers the
contents of userPassword attrib. In some cases this is a hash of some
sort. If you need protection, use ssl. The next version of saslauthd
will also support sasl mechs.

-Igor

> On Wed, 2003-04-16 at 12:11, Jose Miguel Varet wrote:
> > >Unfortunately, openssl 0.9.6b is the problem. Read (section Note about
> > >OpenSSL and crypt()), http://www.openldap.org/faq/data/cache/185.html.
> > >This applies to saslauthd/ldap build or any other app that uses crypt()
> > >and openssl.
> >
> >
> > damn, this openssl issue seems to be the root of the problem, good catching.
> >
> > As for "auth_method : custom", from saslauthd/LDAP_SASLAUTHD doc file :
> >
> > "
> > ldap_auth_method: <bind> <bind|custom|fastbind>
> > Specify an authentication method.
> >
> > The bind method uses the LDAP simple bind facility to verify the
> > password. This is the default.
> >
> > The custom method uses userPassword attribute to verify the
> > password.
> > Currently, {CRYPT} hash is supported.
> > "
> >
> > since I use openLdap's userpassword attribute in order to store user
> > passwords, I supposed this was not "simple bind". Besides, I need the
> > {crypt} hash, since I'm migrating shadow passwords ( which are md5-based
> > {crypt} ) directly to the userpassword attribute.
> > Frankly, I've not tried the "auth_method: bind" . By reading this doc, I
> > always thought that "auth_method : custom" was the way to go when using
> > userpassword attribute . Perhaps I'm wrong here?
> >
> > Greets,
> >
> > Jose,
> >
> >
> > ----- Original Message -----
> > From: "Igor Brezac" <igor at ipass dot net>
> > To: "Jose Miguel Varet" <varet at alvirhosting dot com>
> > Cc: <cyrus-sasl at lists dot andrew dot cmu dot edu>
> > Sent: Wednesday, April 16, 2003 6:55 PM
> > Subject: Re: saslauthd -a ldap ( possible BO / bug with long userpassword
> > strings ? )
> >
> >
> > >
> > > On Wed, 16 Apr 2003, Jose Miguel Varet wrote:
> > >
> > > > Exactly, Mr. Chu is right. Old crypt() implementations hashed the
> > passwords
> > > > in 13 characters, but new crypt()'s include a MD5-based hash, wich looks
> > > > like as long as that one I've provided as an example.
> > > >
> > > > Igor, I just saw your last mail : my OS is Linux 2.4.20 , an heavily
> > > > patched RedHat 7.3 .
> > > > /usr/local/etc/saslauthd.conf , effectively, must have "custom"
> > >
> > > Why?
> > >
> > > > auth_method. Mine looks like :
> > > >
> > > > --------------------------
> > > > ldap_servers: ldap://ldap.testdomain.com
> > > > ldap_search_base: dc=testdomain,dc=com
> > > > ldap_auth_method: custom
> > >
> > > change this to (this should work unless your openldap uses wrong crypt()):
> > >
> > > ldap_auth_method: bind
> > >
> > > > ldap_bind_dn: cn=Manager,dc=testdomain,dc=com
> > > > ldap_bind_pw: manager_secret
> > > > --------------------------
> > > >
> > > > if it's of interest, my openssl version isn't a self-compiled one (
> > > > everything else it's ) , but a just-rpm-it package , openSSL version
> > > > 0.9.6b-18
> > > > I'm aware that this isn't the latest version, and that it has several
> > > > security issues ( timing RSA attack, etc. ) but since this is an
> > internal
> > > > test machine protected from the exterior, I didn't bothered
> > > > upgrading/compiling to the latest openSSL.
> > >
> > > Unfortunately, openssl 0.9.6b is the problem. Read (section Note about
> > > OpenSSL and crypt()), http://www.openldap.org/faq/data/cache/185.html.
> > > This applies to saslauthd/ldap build or any other app that uses crypt()
> > > and openssl.
> > >
> > > > as you say, we know that crypt() isn't the problem , since saslauthd -->
> > > > pam --> ldap with md5-crypt will woek perfectly. It's direct path ,
> > > > saslauthd --> ldap, wich will do the "read size error". This will not
> > happen
> > > > when the password is a *short* string.
> > > >
> > > > Pity, I do not have access to a old-style 13-char crypt() password right
> > > > now, since all of my servers use the new long-md5 crypt function. If I
> > had
> > > > one of these, I'd bet my left hand, that saslauthd ---> ldap via {crypt}
> > > > would work OK, since the userpassword LDAP hash would be a shorter
> > string .
> > > > But again, this is only pure speculation on my hand... developers have
> > the
> > > > last word, of course.
> > >
> > > If you have to use 'ldap_auth_method: custom', you need to fix openssl.
> > > Openssl 0.9.7x is fine. Or build cyrus-sasl with --without-openssl.
> > >
> > > --
> > > Igor
> > >
>

-- 
Igor







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD