Re: password rules - Mailing list pgsql-general

Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
> On 2025-06-25 14:42:26 +0200, raphi wrote:
> [snip]
>> 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? In my tests I configured 
LDAP as described in the documentation: 
https://www.postgresql.org/docs/current/auth-ldap.html

[quote]
Once the user has been found in this search, the server re-binds to the 
directory as this user, using the password specified by the client, to 
verify that the login is correct
[/quote]

And this worked as expected, when the user provided the password stored 
in LDAP, they could login and couldn't when given a wrong (or empty) 
password. Can you elaborate on what you mean?

[snip]
> But do they? "Complexity" (scare quotes intentional) rules are easy to
> circumvent and when people don't see the need for strong passwords, they
> will do so. If they do see the need they will use strong passwords on
> their own and the rules are somewhere between unnecessary and
> counter-productive. Most guidelines also have stopped recommending
> mandatory password rotations quite some time ago.
>
> These features provide convenient boxes for auditors to tick off and
> security for management who can claim that they did something.
> Operational security? Not so much.
>
> (just my personal opinion as someone who's been a sysadmin for over 20
> years (although not recently))
Well, PCI still does. But checking auditors boxes is not the main reason 
I am looking for a solution (because we don't have any PCI applications 
on PG yet anyway) but our self service: An ansible playbook creates a 
role for someone and sends the password by email to the user who wanted 
the role created. This password ought to be temporary and should be 
changed upon first connect. Without any checks we can't neither ensure 
that the password will be changed nor that it won't be reused. We make 
it clear that this should happen and most devs probably do the sensible 
thing and set a new complex password but as you said, some people are 
just lazy and there's no feasable way for us to verify this.

have fun
raphi (who also was once in an almost forgotten lifetime a solaris admin 
for over 20 years ;))