On 2025-06-28 18:06:51 +0200, raphi wrote:
> Am 28.06.2025 um 15:59 schrieb Peter J. Holzer:
> > On 2025-06-27 19:00:36 +0200, raphi wrote:
> >
> > > 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 le
Am 28.06.2025 um 15:59 schrieb Peter J. Holzer:
On 2025-06-27 19:00:36 +0200, raphi wrote:
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 suita
On Sat, Jun 28, 2025 at 9:59 AM Peter J. Holzer 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
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 w
ion
works and that the philosophy is that the postgres server should never
know any passwords. I think that's what Tom tried to say but I failed to
understand it correctly, I thought the issue is not having unencrypted
passwords being sent over the network. So, why this also does not solve
our
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 digit
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 certi
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 10
necessary 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.
vide 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 h
Am 25.06.2025 um 01:20 schrieb Greg Sabino Mullane:
On Mon, Jun 23, 2025 at 2:45 PM raphi wrote:
As of now though we cannot use PG for any PCI/DSS certified
application
because we can't enforce either complexity nor regular password
changes,
You can, and many, many companie
On Mon, Jun 23, 2025 at 2:45 PM raphi wrote:
> As of now though we cannot use PG for any PCI/DSS certified application
> because we can't enforce either complexity nor regular password changes,
>
You can, and many, many companies do, but you need a modern auth system
like Kerberos. Even if we we
Le 24/06/2025 à 07:18, raphi a écrit :
Am 23.06.2025 um 22:39 schrieb Christoph Berg:
Re: raphi
Sorry for this rather long (first) email on this list but I feel
like I had
to explain our usecase and why LDAP is not always as simple as
adding a line
to hba.conf.
Did you give the "pam" metho
Am 23.06.2025 um 22:39 schrieb Christoph Berg:
Re: raphi
Sorry for this rather long (first) email on this list but I feel like I had
to explain our usecase and why LDAP is not always as simple as adding a line
to hba.conf.
Did you give the "pam" method a try? T
Not really because it's a loca
Re: raphi
> Sorry for this rather long (first) email on this list but I feel like I had
> to explain our usecase and why LDAP is not always as simple as adding a line
> to hba.conf.
Did you give the "pam" method a try? There are PAM modules for all
sorts of password checks.
Christoph
Am 23.06.2025 um 17:05 schrieb Tom Lane:
raphi writes:
We can set a password for a role in PG but there is no way to force a
user to change it, prevent reuse or to enforce some complexity on it. As
I understand, that's by choice and when I ask about this, the usual
answer is "that's not the job
raphi writes:
> We can set a password for a role in PG but there is no way to force a
> user to change it, prevent reuse or to enforce some complexity on it. As
> I understand, that's by choice and when I ask about this, the usual
> answer is "that's not the job of a database, use LDAP for it".
Hello all,
I've been lurking for quite a while on the pg lists but now I need some
help or rather, want to start a discussion:
We can set a password for a role in PG but there is no way to force a
user to change it, prevent reuse or to enforce some complexity on it. As
I understand, that's b
18 matches
Mail list logo
