Re: [HACKERS] Enhancements to passwordcheck

On 9/25/17, 8:31 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
> Yes, I have developped a couple of years back a fork of passwordcheck
> which had much similar enhancements, so getting something more modular
> in upstream would be really welcome.

Awesome.

> On top of that I think that you should have a parameter that specifies
> a string full of special characters. For example I have been using
> things like !@#$%^&*()_+{}|<>?=. But you likely want to make that
> modular, people have their own set of character characters, and it is
> just something that could be compared with strchr(), still the default
> should be meaningful.

+1

>>         passwordcheck.superuser_can_bypass
>
> Not sure that this one has much meaning. Superusers could easily
> unload the module.

True.  I can leave it out for now.

>>         passwordcheck.force_new_password
>
> So this is to make sure that the new password is not the same as the
> old one? This would be better with the last N passwords, still this
> would require more facilities. I would discard this one as what you
> are proposing here is not modular enough IMO, and needs a separate
> feature set.

Fair enough.  I'll definitely start with a set of very non-controversial
parameters, as this will likely require rewriting most of the module.

>> I'd like to use this thread to gauge community interest in adding this
>> functionality to this module.  If there is interest, I'll add it to the next
>> commitfest.
>
> I think that's a good idea. Great to see that you are contributing
> back some stuff.

Thanks for the detailed feedback.

On 9/25/17, 8:37 PM, "Euler Taveira" <euler@timbira.com.br> wrote:
>>         passwordcheck.max_expiry_period
>>
> How would you enforce that? If the password expires, you can log in to
> change the password. If you let him/her to get in and change the
> password, you can't obligate the user to do that. You could send a
> message to remember that the password will expire but you can't
> enforce that (unless you make a change in the protocol).

My idea was to tie into the existing password expiration functionality
(VALID UNTIL in CREATE/ALTER ROLE statements).  I don't think this would
involve any changes to how password expiration works.  Instead, it would
just be a simple check to make sure the specified expiration date is not
too far in the future.

>>         passwordcheck.force_new_password
>>
> Does it mean a password different from the old one? +1. It could be
> different from the last 3 passwords but we don't store a password
> history.

Yes.  As Michael pointed out, this might be better to do as a separate
effort since we'll almost certainly need to introduce a way to store
password history.

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.  If we take that route,
perhaps we will also need to ensure that PostgreSQL fails to start when
invalid combinations are specified (e.g. pre-hashed passwords are forced
and min_password_length is nonzero).  Thoughts?

Also, I imagine we'll want to keep the cracklib and "password cannot
contain role name" features around, although perhaps these could become
configurable like the rest of the options.

Nathan


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers