public inbox for [email protected]
help / color / mirror / Atom feedFrom: raphi <[email protected]>
To: [email protected]
Subject: Re: password rules
Date: Wed, 25 Jun 2025 14:42:26 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Am 25.06.2025 um 13:55 schrieb Peter J. Holzer:
> On 2025-06-23 16:35:35 +0200, raphi wrote:
>> To be fair, setting up LDAP is very easy in PG, just one line in hba.conf
>> and all is done. But sadly, that's only where the problems begin. The
>> difficult part is to embedd this setup into a company, especially a large
>> one as I work for with over 1000 PG databases and at least that many roles.
>> Someone needs to be able to manage the passwords in LDAP and this means
>> someone has to decide who can change which passwords, which is usually where
>> some sort of Identity and Access Management (IAM) comes into place.
>>
>> We already have LDAP and IAM in place in our organization for many other
>> things, but IAM identities are coupled to a real person, not a team. Which
>> means only one person in the team would be able to set a new password and
>> when that person leaves the team, IAM rights need to be revoked and given to
>> a new person. Doable, but quite a pane in the behind, especially when that
>> one person happens to be on holidays.
> I don't see why that should be the case. You could either grant
> privileges to more than one person or - preferrably - to a role which is
> then granted to the personal roles.
>
> So for example you would authenticate as «raphi» and I as «hjp» but we
> could both change to «foo_admin» or whatever. That would even have the
> advantage that we leave an audit trail with our "real" identities.
>
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. Technically possible and we have
similar mechanisms in place for other access, but authentication is then
made by key or certificate, ldap/iam is only used to control who can
access what.
But "our" problem aside, I still don't quite understand the decision
that this was never implemented. If password authentication is so bad,
why allow it all then? And when it's allowed, why not provide some basic
features to make it more secure? The lack of any password rules is in it
self the reason why it is so dangerous to use passwords in PG. I'd argue
that the use of passwords with complexity requirements and TTL settings
over an encrypted connection, with firewall rules and proper hba.conf
access lists, are quite safe. Maybe even safer than a central solution
like LDAP or Kerberos which is a single point of entry for an attacker,
be it by attacking the software itself or the backup of the data,
potentially getting access to everything instead of "just" one hacked
password. But now I'm definitely getting into "let's have a beer"
territory... ;)
have fun
raphi
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