Re: Password complexity/history - credcheck?

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Martin Goodson <kaemaril(at)googlemail(dot)com>, Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Password complexity/history - credcheck?
Date: 2024-06-24 08:20:56
Message-ID: 430fce74e2461f26e01ba5ea7ae586b44365894d.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 2024-06-23 at 14:14 +0100, Martin Goodson wrote:
> On 23/06/2024 11:49, Christoph Moench-Tegeder wrote:
> > My advice would be to not use secrets stored in the database -
> > that is, do not use scram-sha-256 - but use an external authentication
> > system, like Kerberos (might be AD) or LDAP (might also be AD) and have
> > that managed by the security team: that way all these compliance
>
> Crikey, that would be  quite a lot of  lot of SSL/TLS to set up. We have quite a
> few (massive understatement :( ... ) PostgreSQL database clusters spread over 
> quite a lot (another understatement) of VMs.
>
> The last time I suggested LDAP there was a lot of enthusiasm ... until they went
> down and looked at what might have to be done, after which it all became very quiet ...

Yes, LDAP is not perfect for that - for one, every connection to the database would
also hit the LDAP server.

Kerberos or certificate authentication is probably better.

For many PostgreSQL clusters and clients, that might be a lot of work.
But not all your PostgreSQL databases will contain equally sensitive data.
You could start with the important ones, try to automatize as much as possible,
and roll out the changes over time.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2024-06-24 08:23:06 Re: Upgrade PG from 12 to latest
Previous Message Kashif Zeeshan 2024-06-24 05:28:13 Re: Stack Smashing Detected When Executing initdb