Re: Failed Login Attempts parameter

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Craig James <cjames(at)emolecules(dot)com>
Cc: Lukasz Brodziak <lukasz(dot)brodziak(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Frank Cavaliero <fcavalie(at)us(dot)ibm(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Failed Login Attempts parameter
Date: 2012-11-16 00:45:11
Message-ID: 20121116004510.GD5162@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

* Craig James (cjames(at)emolecules(dot)com) wrote:
> 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.

Sadly, in certain environments (US Federal organizations which are
required to follow FISMA), a lock-after-X-attempts control is required.

We dealt with this by utilizing the PAM authentication method with
pam_tally. It's kind of ugly, but it can be made to work. Other
alternatives are using Kerberos or Certificate-based authentication
where the user has to acquire initial credenials through some other
mechanism and then those have a limited time of usefulness (eg: Kerberos
tickets only last 10 hours). By using those credentials instead of
having database-based password requirements, you can avoid the entire
problem (along with password ageing, etc..).

Thanks,

Stephen

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Dinesh Bhandary 2012-11-16 01:17:20 openssl-1.0,0e for Solaris 10 64 bit
Previous Message Ronit Allen 2012-11-15 19:35:04 Re: Date range for pg_stat_all_tables?