Re: Failed Login Attempts parameter
| От | Craig James |
|---|---|
| Тема | Re: Failed Login Attempts parameter |
| Дата | |
| Msg-id | CAFwQ8reC+efJpQMhOB0n-BM1LJZy9=X4fgXTG44AUbbtgiubQA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Failed Login Attempts parameter (Lukasz Brodziak <lukasz.brodziak@gmail.com>) |
| Ответы |
Re: Failed Login Attempts parameter
|
| Список | pgsql-admin |
On Thu, Nov 15, 2012 at 1:32 AM, Lukasz Brodziak <lukasz.brodziak@gmail.com> wrote:
Or never. Locking users out invites denial-of-service attacks. All you have to do is figure out someone's username and you can lock them out of the system by deliberately failing login.
A far better approach is an escalating delay. Check the number of failed login attempts N and delay (for example) N^2 seconds before responding again. Legitimate users are mildly inconvenienced, and hackers are severely hampered.
Craig
2012/11/15 Craig Ringer <craig@2ndquadrant.com>
> Another option would be to monitor syslog or the csvlog and lock the
> user out by changing their password or revoking CONNECT rights if they
> trip the threshold. It wouldn't be as responsive to high-rate brute
> forcing attempts but your IDS should be handing those already.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
I wouldn't go with password change approach, at least not
automatically...
Or never. Locking users out invites denial-of-service attacks. All you have to do is figure out someone's username and you can lock them out of the system by deliberately failing login.
A far better approach is an escalating delay. Check the number of failed login attempts N and delay (for example) N^2 seconds before responding again. Legitimate users are mildly inconvenienced, and hackers are severely hampered.
Craig
В списке pgsql-admin по дате отправления: