Re: Rejecting weak passwords

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Dave Page <dpage(at)pgadmin(dot)org>, Marko Kreen <markokr(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Andrew Dunstan <andrew(at)dunslane(dot)net>, mlortiz <mlortiz(at)uci(dot)cu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rejecting weak passwords
Date: 2009-10-14 22:24:38
Message-ID: 1255559078.22713.14.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2009-10-14 at 13:08 -0400, Tom Lane wrote:
> The reason to not want cleartext passwords in the logs is that the
> user doesn't trust the DBA.

I originally implemented the encrypt-on-the-client logic because the
previous way of using ALTER USER ... PASSWORD would promiscuously leave
the clear-text password all over the place, including the psql history,
where it accidentally pops up again when you scroll up, or possibly the
pgAdmin log, and the server log where the DBA can't avoid reading it
even if he doesn't really want to, from where it goes through PgFouine
and onto a web server.

While guarding against a DBA you don't trust is a side-effect of this,
it should not really be a goal. Most password systems that I can think
of pass the cleartext password into address space controlled by the
administrator at some point. The goal should be to keep it there for as
little as possible and not spread it around randomly. But users should
know that the password they enter into any system can be seen by the
administrator of the system.

The canonical solution for a situation where you don't trust anyone is
SSL client certificates.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-10-14 22:25:21 Re: Rejecting weak passwords
Previous Message Tom Lane 2009-10-14 22:23:19 Re: Rejecting weak passwords