Re: Failed Login Attempts parameter - Mailing list pgsql-admin

From Craig James
Subject Re: Failed Login Attempts parameter
Date
Msg-id CAFwQ8reC+efJpQMhOB0n-BM1LJZy9=X4fgXTG44AUbbtgiubQA@mail.gmail.com
Whole thread Raw
In response to Re: Failed Login Attempts parameter  (Lukasz Brodziak <lukasz.brodziak@gmail.com>)
Responses Re: Failed Login Attempts parameter
List pgsql-admin


On Thu, Nov 15, 2012 at 1:32 AM, Lukasz Brodziak <lukasz.brodziak@gmail.com> wrote:
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 by date:

Previous
From: Ravi Kumar
Date:
Subject: How to restore backup
Next
From: Ronit Allen
Date:
Subject: Re: Date range for pg_stat_all_tables?