Thank you for the information! This issue originated from a Department of Defense STIG (Security Technical Implementation Guides). It's a security check that applications and databases have to go through. I'll just leave this one as a "finding" since there isn't a way to really configure it to their requirements.
Thanks again for your help. On Thu, Mar 19, 2020 at 7:19 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Dave Hughes <dhughe...@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. 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 >
