Re: Rejecting weak passwords

On Wed, Oct 14, 2009 at 11:44 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Dave Page <dpage(at)pgadmin(dot)org> writes:
>>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> If you're really intent on making that happen, you can have your
>>>> password checker plugin reject crypted passwords; we don't need
>>>> such a questionable rule in core.
>>
>>> Client software would need to have a standard way to know when to use
>>> ENCRYPTED PASSWORD or not.
>>
>> Oh, so you want us to propagate extra support for this blatant security
>> reduction all over the system too?  No thank you.
>
> You've twice asserted it's a reduction without providing any arguments
> to back that up. I argue that you *possibly* open a very hard to
> exploit hole, which is exploitable only by sysadmins/DBAs, in return
> for which you close a very large hole that allows users to reuse
> passwords or use common or easy to guess words.
>
> If I am incorrect or have missed an important point, please explain why or what.
>
>> This whole line of discussion just proves the point that was made
>> originally: it would be a lot better to do whatever checking you want
>> done on the client side, rather than risk transmitting unencrypted
>> passwords.  If you are going to imagine that client-side software knows
>> about such a GUC, you might as well imagine that they have cracklib
>> built in.
>
> Surely you can see that it is *absolutely pointless* to put an
> password complexity checking in the client? All a user would need to
> do is grab a copy of psql to bypass it. If they can't do that, there's
> probably a scripting language or 12 that would make it similarly easy.

To all of the above, +1.

...Robert