On 2/2/08, Tom Donovan <[EMAIL PROTECTED]> 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 always > 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 hash > > -tom- >
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. -Scott
