2017-09-25 15:04 GMT-03:00 Bossart, Nathan <bossa...@amazon.com>: > 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. 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 > passwordcheck.min_uppercase_letters > passwordcheck.min_lowercase_letters > passwordcheck.min_numbers > passwordcheck.min_special_chars > +1.
> passwordcheck.superuser_can_bypass > It is not clear if it will bypass the checks for (i) a new superuser or (ii) a superuser creating a new role. I wouldn't recommend using such option even tough it is a common practice. > 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). > 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. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
