apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <donov...@bellatlantic.net>
Subject Re: Possible bug in apr_dbd_mysql
Date Fri, 01 Feb 2008 02:44:35 GMT
Scott Sanders wrote:
> Hi,
> After much frustration I was able to get apr_dbd_mysql compiled and 
> working on my machine. However, when testing the module I believe I 
> but in my environment that's OK. My initial apache config to secure this 
> section of the site with basic auth set the AuthDBDUserPWQuery to 
> "SELECT pwd2 FROM users WHERE email=%s AND active=1". This worked and 
> prevented invalid users (and inactive users) from authenticating, but if 
> 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 find that only an empty password works when AuthDBDUserPWQuery retrieves a value of ''.
a non-empty password (in Firefox) gives a "Password Mismatch" error.  I'm using Apache 2.2.8
on Windows.

> This has got to be a bug in the apr_dbd_mysql code, but I unfortunately 
> don't have time right now to track it down and provide a patch. To solve 

Not really.  An empty string is not prohibited as a password unless you prohibit it.
An empty-string is also the valid hash of an empty-string password.

On Windows, BEOS, and Netware - plain-text passwords are used if there is no prefix.
'' is a valid plain-text password.

On Linux, crypt is used if there is no prefix.

   hash = crypt_r(password, salt, buffer)

returns an empty-string as the hash when called with an empty-string password and an empty-string

salt.  I expect most other Unix systems do the same.

> my problem I changed my query to "SELECT pwd2 FROM users WHERE email=%s 
> AND active=1 AND pwd2 !=''" but this is an ugly hack. Where is the 
> bugzilla to file this?

It doesn't seem ugly to me.  If you insist on storing '' in pwd2, yet you don't want it treated
as a 
valid password; then enforcing your rule in SQL seems reasonable.

Existing sites may already use an empty-string password when they want the user to voluntarily
a (valid) username but they don't require any password to verify it.  Not the usual case,
but it 
doesn't seem necessary to break their scheme just to allow for storing empty passwords and
denying them.  As you pointed out, storing a NULL as the password hash will always reject
a login 


View raw message