Thread: Request to Enforce the password Strength for PostgreSQL Databases

Request to Enforce the password Strength for PostgreSQL Databases

From
"Goli, Vijay"
Date:

Hi Team,

 

In Marsh we have the PostgreSQL Databases 9.5.6 version. As per my review of the postgresql direct site & some of the blogs , I see the default limits are below:

 

  • minimum 8 characters
  • password cannot contain username
  • it must contain at least 1 letter and and least 1 non-letter

 

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?

 

I see using “cracklib” we can modify the parameters in the “passwordcheck.dll”. Can you please help how we can implement this ?


Referenced URLS:

 

https://www.depesz.com/2009/12/17/waiting-for-8-5-checking-password-strength/

 

https://www.postgresql.org/docs/current/static/passwordcheck.html

 

 

Thanks for your support in advance.

 

 

Thanks.

Regards,

Vijay Goli, Shared Services – DBA- North America

Marsh | Global IT & Operations | Global Service Delivery
121 River St, Hoboken, NJ 07030, USA
Phone: +(201)-284-6221 | Mobile: + (201)-595-9779 | vijay.goli@marsh.com

www.marsh.com

 





**********************************************************************
This e-mail, including any attachments that accompany it, may contain
information that is confidential or privileged. This e-mail is
intended solely for the use of the individual(s) to whom it was intended to be
addressed. If you have received this e-mail and are not an intended recipient,
any disclosure, distribution, copying or other use or
retention of this email or information contained within it are prohibited.
If you have received this email in error, please immediately
reply to the sender via e-mail and also permanently
delete all copies of the original message together with any of its attachments
from your computer or device.
**********************************************************************

Re: Request to Enforce the password Strength for PostgreSQL Databases

From
Michael Paquier
Date:
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

Attachment