Date: Sat, 28 Jun 2025 15:59:23 +0200
From: "Peter J. Holzer" <hjp-pgsql@hjp.at>
To: pgsql-general@lists.postgresql.org
Subject: Re: password rules
Message-ID: <20250628135923.v2hrctnfjpqlcnqs@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>
 <20250625153305.hmbzbpq5nadwvczo@hjp.at>
 <0344a9b2-bb6b-4d09-af54-2acb10b6a51a@crashdump.ch>
 <20250626122741.wkemjudz3lagw6zn@hjp.at>
 <31fd386e-8cff-4573-8cc7-f4e64c59dc85@crashdump.ch>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="c6e477un2vmwwrqg"
Content-Disposition: inline
In-Reply-To: <31fd386e-8cff-4573-8cc7-f4e64c59dc85@crashdump.ch>
Archived-At: <https://www.postgresql.org/message-id/20250628135923.v2hrctnfjpqlcnqs%40hjp.at>
Precedence: bulk


--c6e477un2vmwwrqg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2025-06-27 19:00:36 +0200, raphi wrote:
>=20
>=20
> Am 26.06.2025 um 14:27 schrieb Peter J. Holzer:
> > On 2025-06-25 17:55:12 +0200, raphi wrote:
> > > Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
> > > > On 2025-06-25 14:42:26 +0200, raphi wrote:
> > > > > That's not how the identiy principle works, at least not how it's
> > > > > implement in our company. A user in ldap has a direct relation to
> > > > > one digital entity, either a token from an application or
> > > > > certificate from a physical person (maybe some AD shenanigans
> > > > > also). We don't have digital entities for teams, 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 role 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.
> > > hmm I don't follow, maybe I was doing it wrong?
> > I'm thinking of something like this:
> >=20
> > Roles assigned to people are in LDAP, and only they have passwords.
> > Application roles don't have to be in LDAP (maybe there are operational
> > reasons to have them there, but PostgreSQL doesn't need them) and don't
> > have passwords.
> Thank you very much for the detailed test. It will be useful for other id=
eas
> I have but (I think) it does not solve our particular case. Maybe I wasn't
> clear enough and I'm sorry for that, but our problem lies in the way how
> applications connect. The passwords that devs are ordering via our self
> service is for the application that is connecting to the database, not for
> themselfs.

Ok. I misunderstood that.

> It's the application's password that we want to ensure that it is
> complex and gets changed after we set an initial password for it.

Why let a human change that at all? Couldn't you just create a suitable
random password at deployment time? (And then automatically every n
months if you want to rotate it.)


> But the more I think about it the more I like switching to
> certificates, after all we already have mechanisms in place to
> automatically get new officially trusted (not selfsigned)
> certificates, it could be adoptable for PG connects too.

I agree. If you already have the infrastructure for that, that's a good
way to avoid some (but not all) of the problems with passwords.

        hjp

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

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

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

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmhf9TMACgkQ8g5IURL+
KF1PBQ//ehaQsHbhp78I6jR3pDqT4EMFvHZ1shK4guFnupU1G8b7TxCicnkYoqMd
eM6rmeRqprt44CeyN9UkS90G6bUezXXJO+k84bCvA/xwkyUu8/bnWn++LZhSetJ2
nKkbjCJBJFDaKBYS676N5hQbNEiqk/3HeQa8eWBy/ihXHda16jgRlQMBDtUn99en
0+hTb59Mo10BAzChsba0u6niggML/PpWb7xtRGGqPsc6blkhh4WhPCBhFdWqO3Fb
89w/8+Wo7klDmJCvWSHaG/jeTaUrI4XGs2bRH4QL30ygO53dTFO5LMZtztVRnCrV
GUbXaCKBm339JNMmaxNbU8LGvKY8NM8r2sdY5QXBYsUz61YVlbAJlP40cDfhsTCN
LIX4GE/6l++TmflkEenh0T1RHiu8FB8DsJR6yDIoY8xQxkTYjTpABWUEbKZpahxk
lVVR1HzB8UFZBvMoPn3Q6Dpa2om6VWDVHlAa6VaLP2bazP8DZug4tZSioQoi5s0U
124dBX7+/CIPHg8CeAlJSWFB8fwIdOn/6B/D0fKXAuAEE27OLxcVTHMqxafEayPq
e4i1H1n+HTFkCJISa9kQHbIqrIeoYAaHvt63/awNa6aOeF7S2anTsmy2kjwKs3Ht
uReF51k3XX+QEop3MiHdsaW9zMWOqYI/P/qypPNDHmvv/yD3YKE=
=APjD
-----END PGP SIGNATURE-----

--c6e477un2vmwwrqg--