Hi,
Citing Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
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.
Direct logins to the database from his machine won't work either, because
the database only allows connections from the webserver.
Regards,
Daniel
