On Sun, Dec 16, 2012 at 04:54:30PM +0100, Murray Cumming wrote:
> libpq lets me open a connection by specifying a password:
> http://www.postgresql.org/docs/9.2/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
>
> Is there any way to specify a hash of the password when connecting, instead of
> providing the password itself?
What's the use of that? It won't buy you any extra protection if the
hash would be accepted as-is instead of the password. In fact, now
you would have *two* strings (instead of one) that are accepted as
equally valid passwords.
> My Web UI asks the user for a PostgreSQL
> username and password, and I want to avoid asking the user for the
> password again later, as long as they have the browser cookie that I set.
Perhaps you can encrypt it in the cookie, to prevent casual onlookers
from discovering the password. However, if anyone can obtain the cookie
(eg via the Firesheep plugin) they can still use that to login even if
they don't know the actual password - they can just reuse the encrypted
blob.
> I've looked at the source of phpPgAdmin, which should deal with the same issue,
> but that seems to store the plaintext password in the session, which might even
> mean that the plaintext password ends up on disk, though I don't know enough about
> PHP to be sure.
The session is slightly safer than storing it directly in the cookie
because one would have to break into the server rather than access
the cookie store in the client. However, if anyone can recover the
session id, they can connect with this user's credentials as well.
> I understand that libpq already sends only an MD5 hash to the
> PostgreSQL server, when it's configured to use MD5 authentication.
I would think that's challenge-response based, but I'm not sure. The
documentation seems to hint that it's just the password, but hashed.
> But I don't want to have to provide a plaintext password to libpq.
Why not? If the script lives on the server, there shouldn't be a way
for the user to recover the password even if it's put in the string.
Unfortunately, I'm not aware of any truly secure method of doing this.
Sorry! Maybe someone else knows of a good approach.
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
