Re: Enhancements to passwordcheck

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enhancements to passwordcheck
Date: 2017-09-26 01:31:09
Message-ID: CAB7nPqRadHgMUGkEp77oq2-vvSAPa1o0gZe0Yi13cXYwaESCGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 26, 2017 at 3:04 AM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> Currently, the passwordcheck module provides a few basic checks to strengthen
> passwords. However, any configuration must be ready at compile time, and many
> common password requirements cannot be enforced without creating a custom
> version of this module.

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.

> I think there are a number of useful parameters that
> could be added to enable common password restrictions, including the following
> list, which is based on some asks from our customers:
>
> passwordcheck.min_password_length

Okay. I have that as well.

> passwordcheck.min_uppercase_letters
> passwordcheck.min_lowercase_letters
> passwordcheck.min_numbers

Those map with isdigit(), isupper() and islower(). Exactly what I have.

> passwordcheck.min_special_chars

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 !(at)#$%^&*()_+{}|<>?=. 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.

> passwordcheck.superuser_can_bypass

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

> passwordcheck.max_expiry_period

Okay. valid_until is passed down to the password hook.

> 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.

> 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.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vaishnavi Prabakaran 2017-09-26 01:36:22 Re: Replication status in logical replication
Previous Message Michael Paquier 2017-09-26 00:51:57 Re: Shaky coding for vacuuming partitioned relations