Horton

Re: Rejecting weak passwords

Dave Page <dpage@pgadmin.org>

View thread View on postgr.es
From: Dave Page <dpage@pgadmin.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Mark Mielke <mark@mark.mielke.cc>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Andrew Dunstan <andrew@dunslane.net>, Marko Kreen <markokr@gmail.com>, Magnus Hagander <magnus@hagander.net>, Greg Stark <gsstark@mit.edu>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers <pgsql-hackers@postgresql.org>, mlortiz <mlortiz@uci.cu>, Albe Laurenz <laurenz.albe@wien.gv.at>
Date: 2009-10-15T18:02:55Z
Lists: pgsql-hackers 
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> OK, so we're in violent agreement here?

From a technical perspective I think we have been for a while. Though
clearly some people disagree with my assertion that putting any form
of policy enforcement in the client is not actually 'enforcement'. I
wonder how many of those folks would implement their website's data
sanitisation in the browser only - but I digress... :-)

> Except for figuring out how
> an API for checking the flag?  Could they just try it with MD5 first
> and then fall back if that say "no MD5"?

That's what I was trying to avoid, as the architecture of pgAdmin
makes that really hard. I know that's not PG's problem, but forcing a
retry is quite an ugly solution anyway, so I was hoping we could come
up with something better.

I suppose in the worst case, I could just have pgAdmin throw the
error, and then add a per-server option to disable password hashing in
the relevant places, but I'd far rather have that automated so it
can't be set unnecessarily.

-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com