Re: Lock Postgres account after X number of failed logins? - Mailing list pgsql-general

From Geoff Winkless
Subject Re: Lock Postgres account after X number of failed logins?
Date
Msg-id CAEzk6ffnR_oZOM2v3_xpTKHxCprfwRTrM1yhhA26rAjHAdtnMw@mail.gmail.com
Whole thread Raw
In response to Re: Lock Postgres account after X number of failed logins?  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Lock Postgres account after X number of failed logins?  (Stephen Frost <sfrost@snowman.net>)
List pgsql-general


On Wed, 6 May 2020, 14:28 Stephen Frost, <sfrost@snowman.net> wrote:
Greetings,

* Geoff Winkless (pgsqladmin@geoff.dj) wrote:
> On Wed, 6 May 2020 at 00:05, Tim Cross <theophilusx@gmail.com> wrote:
> > Where Tom's solution fails is with smaller companies that cannot afford
> > this level of infrastructure.
>
> Is there an objection to openldap? 

LDAP-based authentication in PG involves passing the user's password to
the database server in the clear (or tunneled through SSL, but that
doesn't help if the DB is compromised), so it's really not a good
solution

If your DB is compromised then (if the LDAP server is only used for the db) what difference does it make to lose the passwords?

I was (as per the thread) suggesting a simple way for small companies to achieve the OP's requirements without a large infrastructure investment and without involving the pg team undertaking the rediscovery of novel circular transportation-assisting devices.

Any large company will have an AD or similar setup already, clearly I'm not suggesting using it in that situation.

AIUI you can configure kerberos with openldap if that's more your thing, fwiw, but then IME the learning curve (and thus setup cost) increases exponentially.

Geoff

pgsql-general by date:

Previous
From: Support
Date:
Subject: previous replication slot and new initdb
Next
From: AC Gomez
Date:
Subject: New Role drop with Grant/Revokes stop working after subsequent runs