Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uUJPT-001DyG-9I for pgsql-general@arkaria.postgresql.org; Wed, 25 Jun 2025 06:15:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uUJPR-000FVe-Db for pgsql-general@arkaria.postgresql.org; Wed, 25 Jun 2025 06:15:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uUJPR-000FVV-2E for pgsql-general@lists.postgresql.org; Wed, 25 Jun 2025 06:15:01 +0000 Received: from mx126.mail.hosttech.eu ([82.220.38.13] helo=126.hosttech.eu) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uUJPP-003xwc-2L for pgsql-general@lists.postgresql.org; Wed, 25 Jun 2025 06:15:01 +0000 X-Spam-Status: No X-hosttech-MailScanner-From: raphi@crashdump.ch X-hosttech-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0, required 5, ALL_TRUSTED -1.00, BAYES_50 0.80, HT_185 0.20) X-hosttech-MailScanner: Found to be clean X-hosttech-MailScanner-ID: 14C3F375402F.A98C1 X-hosttech-MailScanner-Information: Please contact the ISP for more information Received: from [192.168.1.205] (31-10-141-228.cgn.dynamic.upc.ch [31.10.141.228]) by 126.hosttech.eu (Postfix) with ESMTPSA id 14C3F375402F; Wed, 25 Jun 2025 08:14:49 +0200 (CEST) Message-ID: <481f66a8-c2e6-424a-a522-7cbe67954b58@crashdump.ch> Date: Wed, 25 Jun 2025 08:14:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: password rules To: Greg Sabino Mullane Cc: Tom Lane , pgsql-general@lists.postgresql.org References: <65b65e9f-b4b0-4927-b872-d24dff11449b@crashdump.ch> <3352511.1750691111@sss.pgh.pa.us> <5f76056a-16b8-49a7-855d-2f8490a3cfe8@crashdump.ch> X-hosttech-server: 126.hosttech.eu From: raphi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Am 25.06.2025 um 01:20 schrieb Greg Sabino Mullane: > On Mon, Jun 23, 2025 at 2:45 PM raphi wrote: > > As of now though we cannot use PG for any PCI/DSS certified > application > because we can't enforce either complexity nor regular password > changes, > > > You can, and many, many companies do, but you need a modern auth > system like Kerberos. Even if we were to put something into Postgres > today (and given the MFA and re-use requirements, it's near > impossible), PCI DSS keeps evolving and getting stricter, so keeping > up with it would get harder with each release. > > Can I do something to help bringing these feature into PG? My C > knowledge is very limited so I won't be able to provide a patch > but I'd be more than happy to test it. > > > Your energy would be much better used in bringing Kerberos into your > organization. :) > Well as said, we have LDAP and IAM widely in use for everything except database access. It's the IAM part that's making it difficult for us to implement it for PG application/user roles, this wouldn't change by using Kerberos instead of LDAP. I thought we'll get the exception from our security to use IAM roles instead of physical persons defined as the owner of the PG accounts but now they are against it. Main reason is because they are looking into a completely different solution with Vault, which would fix some other issues and make it more robust towards PCI, and they prefer a solution for everything rather than making another exception. But we are speaking about years here, 2027 earliest and they haven't even talked to us yet how this would work with PG, only other DB products. have fun, raphi