Re: Lock Postgres account after X number of failed logins?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Wolff, Ken L" <ken(dot)l(dot)wolff(at)lmco(dot)com>
Cc: Allan Kamau <kamauallan(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Subject: Re: Lock Postgres account after X number of failed logins?
Date: 2020-05-05 19:11:00
Message-ID: 10842.1588705860@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Wolff, Ken L" <ken(dot)l(dot)wolff(at)lmco(dot)com> writes:
> I do understand what you described about locking down access through pg_hba.conf, so only authorized users/applications can connect. That makes a lot of sense and I’m going to take it forward to our Information Security organization. However, in case they won’t budge from this requirement, can someone tell me what would be the best way to submit this as a feature request? Simply edit the PostgreSQL Wiki ToDo page (https://wiki.postgresql.org/wiki/Todo) or is there some other method.

It's been discussed, but it's quite unlikely that we'd add features in
this area. The project position is that if you have such requirements,
you can address them by using external authentication management, like
LDAP or PAM. If we tried to take this on board, first we'd have a bunch
of problems with scope creep (because there are so many different random
requirements that people might have), and second we'd have a bunch of
architectural issues with where to keep the relevant state. It can't
be ordinary database state --- at least not if you'd like to use the
feature on read-only slave servers, and even a single server would
have issues executing a transaction from a not-logged-in session ---
but then where *do* we keep it, and how would an admin see or adjust the
state? It's a can of worms we don't really care to open, especially
when there are perfectly good solutions already available outside PG
proper.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter J. Holzer 2020-05-05 19:33:11 Re: Thoughts on how to avoid a massive integer update.
Previous Message Matthias Apitz 2020-05-05 18:12:00 Re: PostgreSQL client hangs sometimes on 'EXEC SQL PREPARE sid_sisisinst FROM :select_anw;'