Daniel Martini <dmartini@uni-hohenheim.de> writes:
> Now how would this work, if it would be possible to send hashed passwords
> from libpq:
> user sends username/password, this gets hashed by the cgi, then the hashed
> value is sent by libpq. Session id is generated and
> stored together with the hashed password in the mapping. Now attacker gets
> hold of the mapping. Assuming he does only have access as the user the cgi
> is running as, he would not have gained anything (except having compromised
> the current sessions, which is less bad than having all passwords in
> cleartext), as he only has the hashed passwords (a brute force attack on
> the hashed values would be possible, but that is at least additional effort
> for the attacker). If he had root, he could install a backdoor allowing
> him to use the hashed passwords, but a compromise like this is much easier
> detected than a compromise based on spied passwords.
What backdoor? AFAICS you are proposing that we add a *front* door for
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.
regards, tom lane
