MIME-Version: 1.0
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>
 <20250628135923.v2hrctnfjpqlcnqs@hjp.at>
In-Reply-To: <20250628135923.v2hrctnfjpqlcnqs@hjp.at>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Sat, 28 Jun 2025 11:14:04 -0400
Message-ID: <CANzqJaDtHhZ2+=HFVSGJajyDmGuoQy_=CxyAKq3u9LkexV8FbA@mail.gmail.com>
Subject: Re: password rules
To: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000007683490638a33f89"
Archived-At: <https://www.postgresql.org/message-id/CANzqJaDtHhZ2%2B%3DHFVSGJajyDmGuoQy_%3DCxyAKq3u9LkexV8FbA%40mail.gmail.com>
Precedence: bulk

--0000000000007683490638a33f89
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 28, 2025 at 9:59=E2=80=AFAM Peter J. Holzer <hjp-pgsql@hjp.at> =
wrote:

> On 2025-06-27 19:00:36 +0200, raphi wrote:
> >
> >
> > 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 settin=
g
> 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 rol=
e
> in
> > > > > the database.
> > > > hmm I don't follow, maybe I was doing it wrong?
> > > I'm thinking of something like this:
> > >
> > > Roles assigned to people are in LDAP, and only they have passwords.
> > > Application roles don't have to be in LDAP (maybe there are operation=
al
> > > 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
> ideas
> > 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 ho=
w
> > 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.)
>

"openssl rand -base64 48" or a couple of random words
from /usr/share/dict/words plus a random number.


> 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
>
> --
>    _  | Peter J. Holzer    | Story must make more sense than reality.
> |_|_) |                    |
> | |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |       challenge!"
>


--=20
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

--0000000000007683490638a33f89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jun 28, 2025 at 9:59=E2=80=AFAM P=
eter J. Holzer &lt;<a href=3D"mailto:hjp-pgsql@hjp.at">hjp-pgsql@hjp.at</a>=
&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">On 2025-06-27 19:00:36 +0200, raph=
i wrote:<br>
&gt; <br>
&gt; <br>
&gt; Am 26.06.2025 um 14:27 schrieb Peter J. Holzer:<br>
&gt; &gt; On 2025-06-25 17:55:12 +0200, raphi wrote:<br>
&gt; &gt; &gt; Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:<br>
&gt; &gt; &gt; &gt; On 2025-06-25 14:42:26 +0200, raphi wrote:<br>
&gt; &gt; &gt; &gt; &gt; That&#39;s not how the identiy principle works, at=
 least not how it&#39;s<br>
&gt; &gt; &gt; &gt; &gt; implement in our company. A user in ldap has a dir=
ect relation to<br>
&gt; &gt; &gt; &gt; &gt; one digital entity, either a token from an applica=
tion or<br>
&gt; &gt; &gt; &gt; &gt; certificate from a physical person (maybe some AD =
shenanigans<br>
&gt; &gt; &gt; &gt; &gt; also). We don&#39;t have digital entities for team=
s, that&#39;s what&#39;s<br>
&gt; &gt; &gt; &gt; &gt; missing. For it to work they (security) would need=
 to allow to<br>
&gt; &gt; &gt; &gt; &gt; weaken this principle and as you said, allow every=
one who has a<br>
&gt; &gt; &gt; &gt; &gt; certain role to manage the associated user in LDAP=
, like setting a<br>
&gt; &gt; &gt; &gt; &gt; new password.<br>
&gt; &gt; &gt; &gt; That user shouldn&#39;t have a password, since nobody i=
s authenticating as<br>
&gt; &gt; &gt; &gt; that user. It also doesn&#39;t have to exist in LDAP. I=
t&#39;s just a role in<br>
&gt; &gt; &gt; &gt; the database.<br>
&gt; &gt; &gt; hmm I don&#39;t follow, maybe I was doing it wrong?<br>
&gt; &gt; I&#39;m thinking of something like this:<br>
&gt; &gt; <br>
&gt; &gt; Roles assigned to people are in LDAP, and only they have password=
s.<br>
&gt; &gt; Application roles don&#39;t have to be in LDAP (maybe there are o=
perational<br>
&gt; &gt; reasons to have them there, but PostgreSQL doesn&#39;t need them)=
 and don&#39;t<br>
&gt; &gt; have passwords.<br>
&gt; Thank you very much for the detailed test. It will be useful for other=
 ideas<br>
&gt; I have but (I think) it does not solve our particular case. Maybe I wa=
sn&#39;t<br>
&gt; clear enough and I&#39;m sorry for that, but our problem lies in the w=
ay how<br>
&gt; applications connect. The passwords that devs are ordering via our sel=
f<br>
&gt; service is for the application that is connecting to the database, not=
 for<br>
&gt; themselfs.<br>
<br>
Ok. I misunderstood that.<br>
<br>
&gt; It&#39;s the application&#39;s password that we want to ensure that it=
 is<br>
&gt; complex and gets changed after we set an initial password for it.<br>
<br>
Why let a human change that at all? Couldn&#39;t you just create a suitable=
<br>
random password at deployment time? (And then automatically every n<br>
months if you want to rotate it.)<br></blockquote><div><br></div><div>&quot=
;openssl rand -base64 48&quot; or a couple of random words from=C2=A0/usr/s=
hare/dict/words plus a random number.</div><div>=C2=A0</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">&gt; But the more I think=
 about it the more I like switching to<br>
&gt; certificates, after all we already have mechanisms in place to<br>
&gt; automatically get new officially trusted (not selfsigned)<br>
&gt; certificates, it could be adoptable for PG connects too.<br>
<br>
I agree. If you already have the infrastructure for that, that&#39;s a good=
<br>
way to avoid some (but not all) of the problems with passwords.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hjp<br>
<br>
-- <br>
=C2=A0 =C2=A0_=C2=A0 | Peter J. Holzer=C2=A0 =C2=A0 | Story must make more =
sense than reality.<br>
|_|_) |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |<br>
| |=C2=A0 =C2=A0| <a href=3D"mailto:hjp@hjp.at" target=3D"_blank">hjp@hjp.a=
t</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 -- Charles Stross, &q=
uot;Creative writing<br>
__/=C2=A0 =C2=A0| <a href=3D"http://www.hjp.at/" rel=3D"noreferrer" target=
=3D"_blank">http://www.hjp.at/</a> |=C2=A0 =C2=A0 =C2=A0 =C2=A0challenge!&q=
uot;<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Death to &lt;Redacted&gt;, and butter sauce.<div=
>Don&#39;t boil me, I&#39;m still alive.<br><div><div>&lt;Redacted&gt; lobs=
ter!</div></div></div></div></div></div>

--0000000000007683490638a33f89--