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
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? |