Horton

Re: Rejecting weak passwords

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dave Page <dpage@pgadmin.org>, Marko Kreen <markokr@gmail.com>, Albe Laurenz <laurenz.albe@wien.gv.at>, Andrew Dunstan <andrew@dunslane.net>, mlortiz <mlortiz@uci.cu>, Magnus Hagander <magnus@hagander.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2009-10-14T17:38:25Z
Lists: pgsql-hackers 
On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.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).

It seems to me incredibly rare for anyone to issue a manual CREATE
USER command with an encrypted password.  And if it is generated by a
script, it will presumably not have a trivial typographical error.

> 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.

Using a non-SSL connection over an untrusted network is incredibly
stupid to begin with.  I'm not sure we should be basing our design
decisions around that scenario.

...Robert