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

Subject: Re: saslauthd -a ldap ( possible BO / bug with long userpassword strings ? )
From: Jose Miguel Varet (varet at alvirhosting dot com)
Date: Wed Apr 16 2003 - 12:14:57 EDT

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"
auth_method. Mine looks like :

ldap_servers: ldap://
ldap_search_base: dc=testdomain,dc=com
ldap_auth_method: custom
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
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.

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.



Hosted Email Solutions

Invaluement Anti-Spam DNSBLs

Powered By FreeBSD   Powered By FreeBSD