Re: password rules

On Sat, Jun 28, 2025 at 9:59 AM Peter J. Holzer <hjp-pgsql(at)hjp(dot)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 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:
> > >
> > > 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
> 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 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.)
>

"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(at)hjp(dot)at | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
>

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