Hi Tom,
Thanks a lot, that was the kind of clarification I needed.
On Fri, Aug 20, 2004 at 10:32:59AM -0400, Tom Lane wrote:
> Daniel Martini <dmartini@uni-hohenheim.de> writes:
> > 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.
With a plain cgi, I probably can't store the data in memory, as the
cgi-process dies as soon as the request is handled (or am I wrong here?).
It would have to be filebased, and a file might be read without being root
(as the cgi has to read it as well and will not be running as root).
Anyways, the solution you proposed below is much better than hashed
passwords in libpq:
> 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).
That looks to me like the most secure way to defend against the database
server being taken fast as well, if the webserver is compromised (as
passwords are nowhere stored in cleartext and can be encrypted quite
strongly and flexible (e.g. different keys for every session etc.).
> 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...
Agreed. Keep libpq simple. I learned that there are better workarounds
against my original problem than adding this to the libpq API.
Regards,
Daniel
