Daniel Martini <dmartini@uni-hohenheim.de> writes:
> Citing Tom Lane <tgl@sss.pgh.pa.us>:
>> ... use of hashed passwords. Maybe the attacker won't know what the
>> original cleartext was, but that adds zero security as far as exploits
>> against the database go. If the webserver can log in with it, so can he.
> No he can't:
> Only if he is able to install a program on the webserver to
> actually login with a hashed password. If he wants to log in over the
> cgi, this won't work, because the hashed value he gained by reading the
> mapping will get hashed again and this will produce a wrong value.
True, but if he can break into the webserver's memory, most likely he can
do that too.
> Direct logins to the database from his machine won't work either, because
> the database only allows connections from the webserver.
[ shrug ] That protection is the same whether you use hashed passwords
or not.
In any case, there are plenty of ways to defend against this scenario
that don't require weird new features in the database API. You could
for instance keep each user/password pair encrypted in the webserver's
memory, using a separate key for each session that is not stored in that
memory (perhaps it is in the cookie you use to identify the session).
Or for that matter, never keep the user/password pair in webserver
memory at all, but instead in the cookie (again encrypted, but this time
the webserver holds the key).
The fact that the password is hashed in a particular way is an
implementation detail that's subject to change, so I don't wish to
expose it as part of the API without darn good reason. I don't see
a darn good reason here...
regards, tom lane
