Mark Adams wrote:
> Another lesson to RTFM! Thanks for your help Chris.
>
> Regards,
> Mark
>
> On Tue, May 04, 2010 at 01:12:20PM +0200, Chris Wilson wrote:
>> Hi Mark,
>>
>>> I've tested again and it is accepting BOTH a blank username and password
>>> as successful.
>> OK, I understood from your initial description that you had already
>> tested this, which is why I didn't suggest it.
>>
>>> We've added in an exception when the user is not found, which causes
>>> exim to receive an error and not accept blank username/password. This
>>> must be a problem with my Exim configuration though. If 0 row's are
>>> returned why isn't the authentication attempt rejected?
>> There is a section on this in the manual:
>>
>> "Warning: If you use a lookup in the expansion to find the user's
>> password, be sure to make the authentication fail if the user is unknown.
>> There are good and bad examples at the end of the next section...
>>
>> Why is this example incorrect? It works fine for existing users, but
>> consider what happens if a non-existent user name is given. The lookup
>> fails, but as no success/failure strings are given for the lookup, it
>> yields an empty string. Thus, to defeat the authentication, all a client
>> has to do is to supply a non-existent user name and an empty password."
>>
>> Your query will return no rows (empty string) for both username and
>> password if the user does not exist. That's probably why this combination
>> is allowed.
>>
>> Cheers, Chris.
>> --
>> _ ___ __ _
>> / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
>> / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
>> \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
>
>
Mark,
Something else to add to your structure and SQL if not already provided for:
IF you make a SELECT that ALSO wants to find a 'true' flag returned from a field
that indicates the user is 'active',
AND you have NOT structured your DB such that 'true' is a default for new
records, but rather 'false' IS a default until manually activated.
THEN you can not only prevent 'at the point of entry' suspended or departed
users from continuing to login and send
BUT ALSO the chances of empty UID + empty PWD matching as a byproduct of
headspace error also go away - the 'active' flag being default 'false' and not
matching if/as/when null.
Likewise, habitual use of 'LIMIT 1' or the like in many places insures you don't
accidentally pull a list or matrix when you were not planning to.
JM2CW
Bill
