Skip site navigation (1) Skip section navigation (2)

Re: Rejecting weak passwords

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-09-28 15:48:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Sep 28, 2009 at 4:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> writes:
>> Tom Lane wrote:
>>> Actually there's a much bigger problem with asking the backend to reject
>>> weak passwords: what ya gonna do with a pre-MD5'd string?  Which is
>>> exactly what the backend is going to always get, in a security-conscious
>>> environment.
>> I'm thinking of the case where somebody changes his or her
>> password interactively on the command line, with pgAdmin III,
>> or similar. People would hardly use the above in that case,
> Really?  If pgAdmin has a password-change function that doesn't use
> client-side password encryption then somebody should file a bug against
> it.  Sending unencrypted passwords exposes the password at least to the
> postmaster logfile.  createuser has been doing encryption, unless
> specifically commanded not to, for a long time.

pgAdmin MD5's the passwords if you use the GUI to change them, or when
add a user. It doesn't make any attempt to parse the SQL if you enter
it yourself in the query tool though (nor is it going to).

Dave Page
EnterpriseDB UK:

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-09-28 15:50:24
Subject: Re: Rejecting weak passwords
Previous:From: Tom LaneDate: 2009-09-28 15:38:45
Subject: Re: Rejecting weak passwords

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group