public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter J. Holzer <[email protected]>
To: [email protected]
Subject: Re: password rules
Date: Sat, 28 Jun 2025 15:59:23 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: password rules
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox