Message-ID: <7b27e37f-f775-4952-96f6-2604ee8259b9@crashdump.ch>
Date: Wed, 25 Jun 2025 14:42:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: password rules
To: pgsql-general@lists.postgresql.org
References: <65b65e9f-b4b0-4927-b872-d24dff11449b@crashdump.ch>
 <20250625115535.bd3lmsslyd36qsha@hjp.at>
From: raphi <raphi@crashdump.ch>
In-Reply-To: <20250625115535.bd3lmsslyd36qsha@hjp.at>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/7b27e37f-f775-4952-96f6-2604ee8259b9%40crashdump.ch>
Precedence: bulk


Am 25.06.2025 um 13:55 schrieb Peter J. Holzer:
> On 2025-06-23 16:35:35 +0200, raphi wrote:
>> To be fair, setting up LDAP is very easy in PG, just one line in hba.c=
onf
>> and all is done. But sadly, that's only where the problems begin. The
>> difficult part is to embedd this setup into a company, especially a la=
rge
>> one as I work for with over 1000 PG databases and at least that many r=
oles.
>> Someone needs to be able to manage the passwords in LDAP and this mean=
s
>> someone has to decide who can change which passwords, which is usually=
 where
>> some sort of Identity and Access Management (IAM) comes into place.
>>
>> We already have LDAP and IAM in place in our organization for many oth=
er
>> things, but IAM identities are coupled to a real person, not a team. W=
hich
>> means only one person in the team would be able to set a new password =
and
>> when that person leaves the team, IAM rights need to be revoked and gi=
ven to
>> a new person. Doable, but quite a pane in the behind, especially when =
that
>> one person happens to be on holidays.
> I don't see why that should be the case. You could either grant
> privileges to more than one person or - preferrably - to a role which i=
s
> then granted to the personal roles.
>
> So for example you would authenticate as =C2=ABraphi=C2=BB and I as =C2=
=ABhjp=C2=BB but we
> could both change to =C2=ABfoo_admin=C2=BB or whatever. That would even=
 have the
> advantage that we leave an audit trail with our "real" identities.
>
That's not how the identiy principle works, at least not how it's=20
implement in our company. A user in ldap has a direct relation to one=20
digital entity, either a token from an application or certificate from a=20
physical person (maybe some AD shenanigans also). We don't have digital=20
entities for teams, that's what's missing. For it to work they=20
(security) would need to allow to weaken this principle and as you said,=20
allow everyone who has a certain role to manage the associated user in=20
LDAP, like setting a new password. Technically possible and we have=20
similar mechanisms in place for other access, but authentication is then=20
made by key or certificate, ldap/iam is only used to control who can=20
access what.

But "our" problem aside, I still don't quite understand the decision=20
that this was never implemented. If password authentication is so bad,=20
why allow it all then? And when it's allowed, why not provide some basic=20
features to make it more secure? The lack of any password rules is in it=20
self the reason why it is so dangerous to use passwords in PG. I'd argue=20
that the use of passwords with complexity requirements and TTL settings=20
over an encrypted connection, with firewall rules and proper hba.conf=20
access lists, are quite safe. Maybe even safer than a central solution=20
like LDAP or Kerberos which is a single point of entry for an attacker,=20
be it by attacking the software itself or the backup of the data,=20
potentially getting access to everything instead of "just" one hacked=20
password. But now I'm definitely getting into "let's have a beer"=20
territory... ;)

have fun
raphi