Re: password rules - Mailing list pgsql-general

Am 23.06.2025 um 17:05 schrieb Tom Lane:
> 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?
> 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".
I'd be open to use an extension for this if there'd be one that is still 
maintained. The seemingly most popular one, credcheck, has an issue open 
for over a year, the password history is not being replicated to the 
standby so we can not use it. The other one, passwordpolicy, hasn't been 
updated in 6 years.
> 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.
We only allow encrypted connections as (hopefully) most do and don't log 
any passwords but I see your point. As said, it's an ongoing battle 
between what DBAs need and what is possible in our environment. After my 
discussion today with our security officer, LDAP will probably never be 
the solution for us because of IAM (which is why I wrote here). He 
mentioned a project for next year where they want to look into a Vault 
solution. It's still password authentication but with complexity, TTL 
and "hidden" from users.

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, 
which is required in PCI - and they are fine with using passwords per 
se, but with constraints. We can with other DB products, which is a 
pitty, it disqualifies PG automatically from the discussion for certain 
applications even when PG would be the better fit. I would've thought 
that this alone would put password handling back on the todo list, 
providing PCI compliance out-of-the-box without the need of additional 
infrastructure would be something to brag about :D Because 20th or 21th 
century, password authentication will probably be used for a long time, 
especially when it's still allowed by PCI and other industry standards.

One last thing, any chance that "valid until" could get a flag where DBA 
can choose if the user will have a chance to set a new password when it 
expires instead of just locking the account? So when it expires, the 
user can still connect but not login, they can only set a new password, 
idealy with some mechanism preventing the user from setting the same 
password as before (compare the input with the current one, e.g. login 
in the background with the pass and when it succeeds, ask the user to 
give a different password or something like that).

have fun,
raphi