Bossart, Nathan wrote:
> On 9/27/17, 7:41 AM, "Peter Eisentraut" <> 
> wrote:
> > On 9/25/17 23:10, Bossart, Nathan wrote:
> >> One interesting design challenge will be how to handle pre-hashed
> >> passwords, since the number of checks we can do on those is pretty
> >> limited.  I'm currently thinking of a parameter that can be used to
> >> block, allow, or force pre-hashed passwords.
> >
> > Pre-hashed passwords are the normal case.  You can't break that without
> > making this module a net loss in security.
> A strength in making this configurable is that you could use it to
> enforce that passwords are pre-hashed.  But yes, blocking pre-
> hashed passwords could be undesirable given an untrusted network or
> server.

I think a password strength check must live at the end that does the
encryption -- something like in psql when you do the \password command,
*before* the encrypted password is sent to the server.  Then you can do
all sort of stuff (... except check for password history).

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.

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to