Re: [HACKERS] Enhancements to passwordcheck

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Enhancements to passwordcheck
Дата
Msg-id CAB7nPqRadHgMUGkEp77oq2-vvSAPa1o0gZe0Yi13cXYwaESCGg@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Enhancements to passwordcheck  ("Bossart, Nathan" <bossartn@amazon.com>)
Список pgsql-hackers
On Tue, Sep 26, 2017 at 3:04 AM, Bossart, Nathan <bossartn@amazon.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 !@#$%^&*()_+{}|<>?=. 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


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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Shaky coding for vacuuming partitioned relations
Следующее
От: Vaishnavi Prabakaran
Дата:
Сообщение: Re: [HACKERS] Replication status in logical replication