public inbox for [email protected]
help / color / mirror / Atom feedRe: password rules
3+ messages / 2 participants
[nested] [flat]
* Re: password rules
@ 2025-06-23 18:44 raphi <[email protected]>
2025-06-24 23:20 ` Re: password rules Greg Sabino Mullane <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: raphi @ 2025-06-23 18:44 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]
Am 23.06.2025 um 17:05 schrieb Tom Lane:
> raphi <[email protected]> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: password rules
2025-06-23 18:44 Re: password rules raphi <[email protected]>
@ 2025-06-24 23:20 ` Greg Sabino Mullane <[email protected]>
2025-06-25 06:14 ` Re: password rules raphi <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Greg Sabino Mullane @ 2025-06-24 23:20 UTC (permalink / raw)
To: raphi <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
On Mon, Jun 23, 2025 at 2:45 PM raphi <[email protected]> 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. :)
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: password rules
2025-06-23 18:44 Re: password rules raphi <[email protected]>
2025-06-24 23:20 ` Re: password rules Greg Sabino Mullane <[email protected]>
@ 2025-06-25 06:14 ` raphi <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: raphi @ 2025-06-25 06:14 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
Am 25.06.2025 um 01:20 schrieb Greg Sabino Mullane:
> On Mon, Jun 23, 2025 at 2:45 PM raphi <[email protected]> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-06-25 06:14 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-06-23 18:44 Re: password rules raphi <[email protected]>
2025-06-24 23:20 ` Greg Sabino Mullane <[email protected]>
2025-06-25 06:14 ` raphi <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox