Re: Rejecting weak passwords - Mailing list pgsql-hackers

From Dave Page
Subject Re: Rejecting weak passwords
Date
Msg-id 937d27e10910151047w1b46d90ara160835a8ceccbe1@mail.gmail.com
Whole thread Raw
In response to Re: Rejecting weak passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Rejecting weak passwords  (Robert Haas <robertmhaas@gmail.com>)
Re: Rejecting weak passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> If we were using some kind of real public key system and someone
>> suggested breaking it to add password complexity checking, I would
>> understand the outrage here.  But I don't understand why everyone is
>> so worked up about having an *optional* *flag* to force plaintext
>> instead of MD5.  I might be wrong here, but can't a determined
>> attacker brute-force an MD5 anyway?  The very fact that people are
>> suggesting that password checking might be feasible even on a
>> pre-MD5'd password by using a dictionary suggests that we're not
>> getting a whole lot of real security here.  And even if not, dude,
>> it's an *optional* *flag*.
>
> Yes, and it's an optional flag that could perfectly well be implemented
> in the plugin that I think we do have consensus to add a hook for.
> The argument is over why do we need to litter the core system with it.

I already said that would suit me. The only other requirement I would
have is a way for pgAdmin or other clients to figure out if that flag
was set so they could construct queries appropriately (and yes, that
could include refusing to send plain text passwords over non-SSL
connections).

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


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Rejecting weak passwords
Next
From: Robert Haas
Date:
Subject: Re: Rejecting weak passwords