Alvaro Herrera <alvherre@surnet.cl> writes:
>> Marko Kreen <marko@l-t.ee> writes:
>>> As for the crypt() case, lets say you have a new user with
>>> hashed password field NULL. In addition, you have client
>>> program that compares crypt() result with hashed field
>>> itself, in addition it handles NULL's as empty string.
>>> Result: it is possible to login with any password.
>>> Lots of assumptions but in eg. PHP case they are all filled.
>>
>> A NULL password field is intended to have exactly that effect, no?
> Not necessarily -- it may mean the user was just created, or it was
> "deactivated" by setting the password to NULL. Yes, this last thing is
> foolish, but people do it anyway ...
Nonetheless, I have a problem with allowing this one scenario to drive a
bizarre design of the function. For every user that is able to omit an
explicit NULL test in this case, there will be ten that have to add one
to avoid their apps blowing up because the function errors out on NULLs.
Just because it's security-related doesn't mean you shouldn't follow the
principle of least surprise and make this SQL function act like 99% of
other SQL functions do when handed a NULL.
And if crypt() should act this way, why not also md5() for instance?
regards, tom lane
