Re: Request to Enforce the password Strength for PostgreSQL Databases

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: "Goli, Vijay" <Vijay(dot)Goli(at)marsh(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Request to Enforce the password Strength for PostgreSQL Databases
Date: 2018-01-04 04:45:04
Message-ID: 20180104044504.GA1218@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jan 03, 2018 at 02:53:27PM +0000, Goli, Vijay wrote:
> As per our Organization standards, we need to have the below limitations:
>
> 1. Password length should be minimum of 15 characters.
> 2. Password should contain at least one digit, one upper and lower
> case character and one punctuation.
> 3. New Password should differ by atleast 3 characters.
>
> Can you please help if we can modify the content in
> "passwordcheck.dll" lib if possible to set the above standards and
> how? Also, if the current PostgreSQL DB 9.5.6 version does not have
> feasibility and is there any future versions which contains these
> changes?

The answer is yes, you can modify passwordcheck. Perhaps you should have
a look at the following module that I have developped which is based on
passwordcheck, except that it has an extra set of switches which allow
more finely-grained policies:
https://github.com/michaelpq/pg_plugins/tree/master/passwordcheck_extra

If you develop a patch to improve passwordcheck with a patch, there is
still time for integration with v11, and you would be likely interested
in the following thread:
https://www.postgresql.org/message-id/AC785D69-41EC-4D0A-AC37-1F9FF55C9E34@amazon.com

After that the packaging is on you. For Windows, when compiling with
Visual Studio, you can just fork the set of scripts in src/tools/msvc
and copy the module you'd like to compile in contrib/. You can also use
the basic set of perl APIs present in the code tree to do
out-of-the-tree compilation, but that requires skills a bit more
advanced (I tend to do the second for some of my stuff, that's more
portable long-term and needs no patching of upstream Postgres).
--
Michael

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2018-01-04 04:52:17 Re: Replication questions - read-only and temporary read/write slaves
Previous Message Jordan Deitch 2018-01-03 21:44:12 Re: Mailing list archiver