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