apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <li...@jssjr.com>
Subject Re: Possible bug in apr_dbd_mysql
Date Mon, 04 Feb 2008 23:05:05 GMT
On 2/2/08, Tom Donovan <donovant@bellatlantic.net> wrote:
> Scott Sanders wrote:
> >     Scott Sanders wrote:
> >      > the pwd2 field was empty then any password would succeed. If pwd2 was
> >      > NULL then the user was rejected, and if pwd2 had a string in it
> >     the user
> >      > was rejected (excepting, of course, when pwd2 had the proper
> >     encrypted
> >      > content).
> >
> > I am able to reproduce this bug on another machine. Apache 2.2.8, MySQL
> > 5.0.22, APR 1.2.12, APR-Util 1.2.12 installed on CentOS 5 x86. Test
> > table and data created with:
> ...
> >
> > Having an empty password is perfectly valid, however, the bug is that as
> > long as the user is valid (i.e. the AuthDBDUserPWQuery doesn't return an
> > empty set) and the password field in the database is empty, any password
> > will authenticate the user.
> You are right.  Testing on Debian 4.0 shows that the Linux crypt(password, salt) function
> returns an empty string whenever the salt argument is an empty string, regardless of
the password.
> If your password hash is an empty string, then as you observed - any password will work
on Linux.
> The crypt docs are at  http://www.gnu.org/software/libc/manual/html_node/crypt.html
> They don't say anything about what to expect when the "salt" argument is empty.
> Note that this is not related to DBD.  An empty-string hash in a file (or in a dbm) behaves
the same
> way. This is Linux crypt() behavior, not anything that Apache does.
> You could log a GNU/crypt bug if you want, but I doubt you will get any answer except:
>    "don't store an empty string as the password hash"
> > I admit I have not turned on debugging and traced into the problem yet.
> > Any tips on where to start looking would be appreciated.
> The call to crypt_r() is at srclib/apr-util/crypto/apr_md5.c line 711.
> The first two arguments to crypt_r() are 1) the user-entered password, and 2) the password
> -tom-


Thanks for taking the time to offer an explanation for this. I have
posted to the GNU Crypto lists just in case this is a bug and not the
expected behavior.


View raw message