Обсуждение: Passwordcheck configuration

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

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.

On Thu, Mar 19, 2020 at 07:19:06PM -0400, Tom Lane wrote:
> 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.

Here is an example:
https://github.com/michaelpq/pg_plugins/tree/master/passwordcheck_extra

> (I seem to recall some recent discussion about deprecating/removing
> passwordcheck altogether, but I can't find it right now.)

This was mentioned last here if I recall correctly:
https://www.postgresql.org/message-id/AC785D69-41EC-4D0A-AC37-1F9FF55C9E34@amazon.com
--
Michael

On Fri, 2020-03-20 at 12:30 -0400, Dave Hughes wrote:
> 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.  

Our traditional answer is that for high security standards, you shouldn't use
passwords in the database, but some external authentication method like
Kerberos.  Then you can enforce the password restrictions there.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) 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.

Trying to do this with PAM really isn't reasonable in my experience, and
I've been there and have gone through the foolishness required to make
it work (in a couple different ways).  PG doesn't run as root though and
many PAM modules expect that, so you end up having to deal with
something like pam_sasl and saslauthd, which is a pain.  I really don't
think it's reasonable for us to be recommending this, and it doesn't
work if what you actually want is for PG to be storing the passwords
(without something like pam_pgsql, but that requires things like the
password being passed to PG in cleartext on every authentication, and is
awkward to set up...).

Basically, you can hack things up enough to get the password complexity
requirement, kind of (note that you can't use \password with psql, for
example, or any other client-side password change mechanism through PG,
so you have to force password changes to be done during authentication,
which is bizarre- users can't change their own password whenever they
wish but rather only when PAM forces them to), but you then end up
running a system that has passwords in the clear being sent to PG by
the client, which is certainly no good.

> The only native capability in that direction is that you can set a
> password expiration date.

Right, which is unfortunate- we should have a better solution.

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

Having the password sent to the server during a PW change isn't great,
certainly, but it's far worse to have the password sent in the clear to
the server on every authentication, which is what using something like
PAM ends up doing.

> > 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 believe some people actually do use it, as it can be compiled with
cracklib, which can be configured.

> (I seem to recall some recent discussion about deprecating/removing
> passwordcheck altogether, but I can't find it right now.)

+1 for my part to dropping it, and replacing it with a proper built-in
capability here, that would work with our SCRAM-based auth.

Thanks,

Stephen

Greetings,

* Dave Hughes (dhughes20@gmail.com) wrote:
> 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.

I believe the PG STIG encourages using PKI instead of using passwords
for authentication.

Thanks,

Stephen