Re: password rules - Mailing list pgsql-general

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.)


> 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!"