Re: Enhancements to passwordcheck

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "'Michael Paquier *EXTERN*'" <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enhancements to passwordcheck
Date: 2017-09-29 06:48:11
Message-ID: A737B7A37273E048B164557ADEF4A58B72222F23@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier wrote:
> On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> I think the passwordcheck module as a whole is a dead end, security-
>> wise. Myself, I've never seen the point in it. It runs at the wrong
>> time, and there's no way to fix that.
>
> Client commands may be run on a trusted network as well, let's not
> forget that. But I definitely agree that this is bad practice in
> general to not hash passwords beforehand. Another thing that
> passwordcheck is good at is being an example of hook use. I would
> think that many people refer to it when implementing their own module
> for whatever they want.

Right.

I originally only wanted the hook, but was lobbied into writing the
contrib module as well, to
a) have a nice checkbox item for ill-concieved security check lists
b) have an example of how the hook could be used.

I still think that there is nothing wrong with adding some GUCs
to the module, as long as there is nothing in it that can compromise
overall security.

Yours,
Laurenz Albe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-09-29 06:48:30 Re: pgbench stuck with 100% cpu usage
Previous Message Michael Paquier 2017-09-29 06:06:51 Re: Bug with pg_basebackup and 'shared' tablespace