Re: libpq: passwords WAS: scripting & psql issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Martini <dmartini(at)uni-hohenheim(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: libpq: passwords WAS: scripting & psql issues
Date: 2004-08-20 00:31:06
Message-ID: 14125.1092961866@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Daniel Martini <dmartini(at)uni-hohenheim(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-08-20 00:45:48 Re: function runs on Windows not on solaris
Previous Message snpe 2004-08-20 00:19:55 Re: Postgresql feature