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-
