Passwordcheck configuration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Passwordcheck configuration

Dave Hughes
Hello,
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. 

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?  The documentation (https://www.postgresql.org/docs/11/passwordcheck.html) says it can be configured using CrackLib, but again I don't see "how" you go about setting this up.

Does anyone know of any documentation that shows you "how" to set up specific requirements?

Thanks in advance,
Dave Hughes
Reply | Threaded
Open this post in threaded view
|

Re: Passwordcheck configuration

Tom Lane-2
Dave Hughes <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Passwordcheck configuration

Dave Hughes
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 <[hidden email]> wrote:
Dave Hughes <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Passwordcheck configuration

Ron-2
In reply to this post by Tom Lane-2
On 3/19/20 6:19 PM, Tom Lane wrote:

> Dave Hughes <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Passwordcheck configuration

Michael Paquier-2
In reply to this post by Tom Lane-2
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@...
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Passwordcheck configuration

Laurenz Albe
In reply to this post by Dave Hughes
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



Reply | Threaded
Open this post in threaded view
|

Re: Passwordcheck configuration

Stephen Frost
In reply to this post by Tom Lane-2
Greetings,

* Tom Lane ([hidden email]) wrote:
> Dave Hughes <[hidden email]> 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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Passwordcheck configuration

Stephen Frost
In reply to this post by Dave Hughes
Greetings,

* Dave Hughes ([hidden email]) 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

signature.asc (836 bytes) Download Attachment