Re: Rejecting weak passwords

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: 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>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rejecting weak passwords
Date: 2009-10-14 16:25:25
Message-ID: 14883.1255537525@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dave Page <dpage(at)pgadmin(dot)org> writes:
> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I see one, and I proposed masking passwords in any relevant queries
> before they were written to the stats or logs to mitigate that.

Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
throw a syntax error before you realize there's anything there that
might need to be protected).

And you ignored the question of insecure transmission pathways, anyway.
By the time the backend has figured out that it's got a CREATE USER
... PASSWORD command, it's already way too late if the client sent it
over a non-SSL connection.

Marko has pointed out repeatedly that a plugin can catch the worst
cases of insecure passwords even when given a pre-md5'd password.
So you can use a plugin that does it that way, or if you want you
can use a plugin that throws error on a pre-md5'd password. I do
not see a reason for us to add a boatload of questionable logic
that favors the latter approach.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2009-10-14 16:37:43 ECPG: store own copy of the prepared statement name
Previous Message Jeff Davis 2009-10-14 16:19:15 Re: alpha 2 release notes