On 3/19/20 6:19 PM, Tom Lane wrote:
> Dave Hughes <dhughes20@gmail.com> writes:
>> I have a requirement to set some password complexity for our database such
>> as length of password, upper case, lower case, special characters,
>> expiration limit, reuse, etc.
> Usually, if you have to do something like that, we recommend setting PG to
> use PAM authentication and configuring the restrictions on the PAM side.
> The only native capability in that direction is that you can set a
> password expiration date.
>
> Note that it's widely believed that this sort of thing makes you LESS
> secure, not more.
Correct.
https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret
NIST Special Publication 800-63B
Digital Identity Guidelines
5.1.1.2 Memorized Secret Verifiers
"Verifiers SHALL require subscriber-chosen memorized secrets to be at least
8 characters in length."
"Verifiers SHOULD NOT impose other composition rules (e.g., requiring
mixtures of different character types or prohibiting consecutively repeated
characters) for memorized secrets."
"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily
(e.g., periodically)."
> Quite aside from the well-established fact that forced
> password changes are bad from a human-factors standpoint, you can't check
> any of those other points unless the password is sent to the server as
> cleartext. That creates its own set of vulnerabilities, and I don't
> know of anybody who considers it good practice.
>
>> I saw there was a module you can use for this called passwordcheck. Seems
>> easy to install, but I don't see how you can configure it for you specific
>> needs?
> passwordcheck hasn't got any out-of-the-box configurability. It's mainly
> meant as sample code that people could modify if they have a mind to.
>
> (I seem to recall some recent discussion about deprecating/removing
> passwordcheck altogether, but I can't find it right now.)
>
> regards, tom lane
>
>
--
Angular momentum makes the world go 'round.