From: Tom Lane <tgl@sss.pgh.pa.us>
To: raphi <raphi@crashdump.ch>
cc: pgsql-general@lists.postgresql.org
Subject: Re: password rules
In-reply-to: <65b65e9f-b4b0-4927-b872-d24dff11449b@crashdump.ch>
References: <65b65e9f-b4b0-4927-b872-d24dff11449b@crashdump.ch>
Comments: In-reply-to raphi <raphi@crashdump.ch>
	message dated "Mon, 23 Jun 2025 16:35:35 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3352510.1750691111.1@sss.pgh.pa.us>
Date: Mon, 23 Jun 2025 11:05:11 -0400
Message-ID: <3352511.1750691111@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3352511.1750691111%40sss.pgh.pa.us>
Precedence: bulk

raphi <raphi@crashdump.ch> writes:
> We can set a password for a role in PG but there is no way to force a 
> user to change it, prevent reuse or to enforce some complexity on it. As 
> I understand, that's by choice and when I ask about this, the usual 
> answer is "that's not the job of a database, use LDAP for it".
> ...
> Is there any chance PG will provide this natively or are there any 
> technical limitations I am unaware of?

I think we have pretty much decided that that will never be part of
core Postgres.  If you don't like using an extension for it, you're
out of luck.  (The core developers have too much to do already, so
we are never going to be receptive to arguments like "I don't want
to use an extension".  But in this case the space of possible
requirements is so large that it doesn't make sense to try to build
a one-size-fits-all in-core solution.)

Extension or not, there are serious objections to many aspects of
such a feature, namely that they can't be enforced without requiring
clients to send cleartext passwords to the server.  That in itself
is a security problem.  For that matter, the whole business of using
passwords rather than other ID technologies (SSL certificates,
Kerberos/GSS tickets, etc) is feeling pretty twentieth-century.

			regards, tom lane