Date: Wed, 25 Jun 2025 17:33:05 +0200
From: "Peter J. Holzer" <hjp-pgsql@hjp.at>
To: pgsql-general@lists.postgresql.org
Subject: Re: password rules
Message-ID: <20250625153305.hmbzbpq5nadwvczo@hjp.at>
Mail-Followup-To: pgsql-general@lists.postgresql.org
References: <65b65e9f-b4b0-4927-b872-d24dff11449b@crashdump.ch>
 <20250625115535.bd3lmsslyd36qsha@hjp.at>
 <7b27e37f-f775-4952-96f6-2604ee8259b9@crashdump.ch>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="a5wjleqpadktv4aq"
Content-Disposition: inline
In-Reply-To: <7b27e37f-f775-4952-96f6-2604ee8259b9@crashdump.ch>
Archived-At: <https://www.postgresql.org/message-id/20250625153305.hmbzbpq5nadwvczo%40hjp.at>
Precedence: bulk


--a5wjleqpadktv4aq
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2025-06-25 14:42:26 +0200, raphi wrote:
>=20
>=20
> 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.=
conf
> > > 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 l=
arge
> > > one as I work for with over 1000 PG databases and at least that many =
roles.
> > > Someone needs to be able to manage the passwords in LDAP and this mea=
ns
> > > someone has to decide who can change which passwords, which is usuall=
y where
> > > some sort of Identity and Access Management (IAM) comes into place.
> > >=20
> > > We already have LDAP and IAM in place in our organization for many ot=
her
> > > things, but IAM identities are coupled to a real person, not a team. =
Which
> > > 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 g=
iven 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 is
> > then granted to the personal roles.
> >=20
> > So for example you would authenticate as =ABraphi=BB and I as =ABhjp=BB=
 but we
> > could both change to =ABfoo_admin=BB or whatever. That would even have =
the
> > advantage that we leave an audit trail with our "real" identities.
> >=20
> That's not how the identiy principle works, at least not how it's impleme=
nt
> in our company. A user in ldap has a direct relation to one digital entit=
y,
> either a token from an application or certificate from a physical person
> (maybe some AD shenanigans also). We don't have digital entities for team=
s,
> that's what's missing. For it to work they (security) would need to allow=
 to
> weaken this principle and as you said, allow everyone who has a certain r=
ole
> to manage the associated user in LDAP, like setting a new password.

That user shouldn't have a password, since nobody is authenticating as
that user. It also doesn't have to exist in LDAP. It's just a role in
the database.


> But "our" problem aside, I still don't quite understand the decision that
> this was never implemented. If password authentication is so bad, why all=
ow
> it all then?

Legacy (posgresql is old). And also hard to avoid if you want to be
usable on a wide variety of platforms and in a wide variety of
situations.

> And when it's allowed, why not provide some basic features to
> make it more secure?

But do they? "Complexity" (scare quotes intentional) rules are easy to
circumvent and when people don't see the need for strong passwords, they
will do so. If they do see the need they will use strong passwords on
their own and the rules are somewhere between unnecessary and
counter-productive. Most guidelines also have stopped recommending
mandatory password rotations quite some time ago.

These features provide convenient boxes for auditors to tick off and
security for management who can claim that they did something.
Operational security? Not so much.

(just my personal opinion as someone who's been a sysadmin for over 20
years (although not recently))

> The lack of any password rules is in it self the reason
> why it is so dangerous to use passwords in PG. I'd argue that the use of
> passwords with complexity requirements and TTL settings over an encrypted
> connection, with firewall rules and proper hba.conf access lists, are qui=
te
> safe.

I agree with you that they can be quite safe. I would claim that
complexity requirements and TTL settings play only a miniscule role in
that.

> Maybe even safer than a central solution like LDAP or Kerberos which
> is a single point of entry for an attacker, be it by attacking the softwa=
re
> itself or the backup of the data, potentially getting access to everything
> instead of "just" one hacked password.

Agree. In fact, all our databases are intentionally not linked to AD.

        hjp

--=20
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

--a5wjleqpadktv4aq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmhcFqgACgkQ8g5IURL+
KF1ofQ//WDOizCf+DnNY+tZ4vUXqyAIEYJzv0AxSqm7FsuvtRWZy7lbPxPLcvrIg
Z7c1XElBbmD2TbCD/IrPbkk+gboIBp25LzhAAP8lcM6Ytnyvxh6cOZffMtMYDKy1
sEYDaG/hHqaLG3SGfah4GuPisYMSxivC/9sibHS9XrFdIZk8/EgQbreaaOCHMXmE
ecXteotRGknfq3MnR7OKtrWFM2paCTCOv3ntjMo7yL5Dr5cZ1C81ACqAO1g+C0OM
Jm1JouvtESdtmJ+Se2v3vbiDWtu4RSi2o+Sgmel3uBR0O/ZZlNpcFNeB13LsCzre
3f+Qj9lNW/OEt5S8yeGUuQQik82FYXxkfH95gx/jMUPAFsaZM2lvZ/BgxYchf1V+
qzKxpjJp5ucjS4nXN3GvSNlT6U0NRfH9MAMCwsDdNabB+vU/pSRTj1liwSGLlAOy
4ZoVMs7ZfH+krDYgiAE1neD2001YnFOQyoegstZ94dEprqmn4bUux4qfaniICSz8
DidzOe7fh6oBHuSrOC8bXFcp90dy55DTOf90CTpu8HUe3Gyjez2HHoC0g6Ejmmuy
ZGWzZinBMKB4Aqkt/PufuDY1vbECYOHdUGRPyVdkIrwVtrGBs81lbBEzztQn2uEk
QatATmRxczMt31sW4jswTp+LAzJN8L8Ii6m7unn7TE8UFPXOSXw=
=C5Nw
-----END PGP SIGNATURE-----

--a5wjleqpadktv4aq--