pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedFailed Login Attempts parameter
7+ messages / 5 participants
[nested] [flat]
* Failed Login Attempts parameter
@ 2012-11-14 21:11 Frank Cavaliero <fcavalie@us.ibm.com>
2012-11-15 08:40 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: Frank Cavaliero @ 2012-11-14 21:11 UTC (permalink / raw)
To: pgsql-admin
Hi,
I've been searching the web and reviewing documentation, but I cannot find
any reference to whether or not a parameter, for example,
failed_login_attempts, exists in PostgreSQL that determines the number of
attempts a user can make before being locked. In addition, if such a
parameter or similar setup exists, is there also some database object that
provides a current count of the failed login attempts?
Thanks,
Frank
Frank Cavaliero
Database Administrator
IBM Infosphere Guardium
IBM Software Group, Information Management
978-899-3635 - Direct
For Technical Services Support Please Call 978-899-9195.
This communication is intended only for the use of the individual or
entity named as the addressee. It may contain information which is
privileged and/or confidential under applicable law. If you are not the
intended recipient or such recipient's employee or agent, you are hereby
notified that any dissemination, copy or disclosure of this communication
is strictly prohibited. If you have received this communication in error,
please immediately notify us at 978-899-9195 or notify the sender by reply
e-mail and expunge this communication without making any copies. Thank
you for your cooperation.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Failed Login Attempts parameter
2012-11-14 21:11 Failed Login Attempts parameter Frank Cavaliero <fcavalie@us.ibm.com>
@ 2012-11-15 08:40 ` Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 08:48 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 09:21 ` Re: Failed Login Attempts parameter Craig Ringer <craig@2ndQuadrant.com>
0 siblings, 2 replies; 7+ messages in thread
From: Lukasz Brodziak @ 2012-11-15 08:40 UTC (permalink / raw)
To: Frank Cavaliero <fcavalie@us.ibm.com>; +Cc: pgsql-admin
Hi,
As far as I know there is no such parameter in PG. If you use PG as a
database for your program you can implement the feature in the appplication
by logging the failed logins in separate table(or the one holding
application users and their passwords) and then disable login for the user
if number of failures is bigger than specified value.
Another way is to create a function in postgresql which will check failed
login count and if the attempts go bigger than specified number it will run
a REVOKE on the user role thus disabling login. Then admin will have to run
GRANT for the user manually.
2012/11/14 Frank Cavaliero <fcavalie@us.ibm.com>
> Hi,
>
> I've been searching the web and reviewing documentation, but I cannot find
> any reference to whether or not a parameter, for example,
> failed_login_attempts, exists in PostgreSQL that determines the number of
> attempts a user can make before being locked. In addition, if such a
> parameter or similar setup exists, is there also some database object that
> provides a current count of the failed login attempts?
>
> Thanks,
> Frank
>
>
> *Frank Cavaliero*
>
> *Database Administrator*
>
> *IBM Infosphere Guardium*
>
> *IBM Software Group, Information Management*
>
> *978-899-3635 - Direct*
>
> For Technical Services Support Please Call 978-899-9195.
>
>
> This communication is intended only for the use of the individual or
> entity named as the addressee. It may contain information which is
> privileged and/or confidential under applicable law. If you are not the
> intended recipient or such recipient's employee or agent, you are hereby
> notified that any dissemination, copy or disclosure of this communication
> is strictly prohibited. If you have received this communication in error,
> please immediately notify us at 978-899-9195 or notify the sender by
> reply e-mail and expunge this communication without making any copies.
> Thank you for your cooperation.
>
>
>
>
--
Łukasz Brodziak
"Do you bury me when I'm gone
Do you teach me while I'm here
Just as soon I belong
Then it's time I disappear"
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Failed Login Attempts parameter
2012-11-14 21:11 Failed Login Attempts parameter Frank Cavaliero <fcavalie@us.ibm.com>
2012-11-15 08:40 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
@ 2012-11-15 08:48 ` Lukasz Brodziak <lukasz.brodziak@gmail.com>
1 sibling, 0 replies; 7+ messages in thread
From: Lukasz Brodziak @ 2012-11-15 08:48 UTC (permalink / raw)
To: Frank Cavaliero <fcavalie@us.ibm.com>; +Cc: pgsql-admin
A little suplement to previous answer You can also automate GRANT process
by creating a table called e.g. locked_users containing role name and
revoke timestamp then make a function that will check the time passed since
revoking permissions for each user and if it will by equal or higher than
time given e.g. 24 hours it will run GRANT LOGIN on the role.
2012/11/15 Lukasz Brodziak <lukasz.brodziak@gmail.com>
> Hi,
>
> As far as I know there is no such parameter in PG. If you use PG as a
> database for your program you can implement the feature in the appplication
> by logging the failed logins in separate table(or the one holding
> application users and their passwords) and then disable login for the user
> if number of failures is bigger than specified value.
> Another way is to create a function in postgresql which will check failed
> login count and if the attempts go bigger than specified number it will run
> a REVOKE on the user role thus disabling login. Then admin will have to run
> GRANT for the user manually.
>
>
> 2012/11/14 Frank Cavaliero <fcavalie@us.ibm.com>
>
>> Hi,
>>
>> I've been searching the web and reviewing documentation, but I cannot
>> find any reference to whether or not a parameter, for example,
>> failed_login_attempts, exists in PostgreSQL that determines the number of
>> attempts a user can make before being locked. In addition, if such a
>> parameter or similar setup exists, is there also some database object that
>> provides a current count of the failed login attempts?
>>
>> Thanks,
>> Frank
>>
>>
>> *Frank Cavaliero*
>>
>> *Database Administrator*
>>
>> *IBM Infosphere Guardium*
>>
>> *IBM Software Group, Information Management*
>>
>> *978-899-3635 - Direct*
>>
>> For Technical Services Support Please Call 978-899-9195.
>>
>>
>> This communication is intended only for the use of the individual or
>> entity named as the addressee. It may contain information which is
>> privileged and/or confidential under applicable law. If you are not the
>> intended recipient or such recipient's employee or agent, you are hereby
>> notified that any dissemination, copy or disclosure of this communication
>> is strictly prohibited. If you have received this communication in error,
>> please immediately notify us at 978-899-9195 or notify the sender by
>> reply e-mail and expunge this communication without making any copies.
>> Thank you for your cooperation.
>>
>>
>>
>>
>
>
> --
> Łukasz Brodziak
> "Do you bury me when I'm gone
> Do you teach me while I'm here
> Just as soon I belong
> Then it's time I disappear"
>
--
Łukasz Brodziak
"Do you bury me when I'm gone
Do you teach me while I'm here
Just as soon I belong
Then it's time I disappear"
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Failed Login Attempts parameter
2012-11-14 21:11 Failed Login Attempts parameter Frank Cavaliero <fcavalie@us.ibm.com>
2012-11-15 08:40 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
@ 2012-11-15 09:21 ` Craig Ringer <craig@2ndQuadrant.com>
2012-11-15 09:32 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
1 sibling, 1 reply; 7+ messages in thread
From: Craig Ringer @ 2012-11-15 09:21 UTC (permalink / raw)
To: Lukasz Brodziak <lukasz.brodziak@gmail.com>; +Cc: Frank Cavaliero <fcavalie@us.ibm.com>; pgsql-admin
On 11/15/2012 04:40 PM, Lukasz Brodziak wrote:
> Hi,
>
> As far as I know there is no such parameter in PG. If you use PG as a
> database for your program you can implement the feature in the
> appplication by logging the failed logins in separate table(or the one
> holding application users and their passwords) and then disable login
> for the user if number of failures is bigger than specified value.
> Another way is to create a function in postgresql which will check
> failed login count and if the attempts go bigger than specified number
> it will run a REVOKE on the user role thus disabling login. Then admin
> will have to run GRANT for the user manually.
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Failed Login Attempts parameter
2012-11-14 21:11 Failed Login Attempts parameter Frank Cavaliero <fcavalie@us.ibm.com>
2012-11-15 08:40 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 09:21 ` Re: Failed Login Attempts parameter Craig Ringer <craig@2ndQuadrant.com>
@ 2012-11-15 09:32 ` Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 16:24 ` Re: Failed Login Attempts parameter Craig James <cjames@emolecules.com>
0 siblings, 1 reply; 7+ messages in thread
From: Lukasz Brodziak @ 2012-11-15 09:32 UTC (permalink / raw)
To: Craig Ringer <craig@2ndquadrant.com>; +Cc: Frank Cavaliero <fcavalie@us.ibm.com>; pgsql-admin
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 this can be done 'on user's demand' at any point. I
admit that I wasn't specific in my solution with REVOKE as I didn't
say which rights should be revoked I of course mean revoke connect
command as Craig was kind to mention.
Regards
--
Łukasz Brodziak
"Do you bury me when I'm gone
Do you teach me while I'm here
Just as soon I belong
Then it's time I disappear"
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Failed Login Attempts parameter
2012-11-14 21:11 Failed Login Attempts parameter Frank Cavaliero <fcavalie@us.ibm.com>
2012-11-15 08:40 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 09:21 ` Re: Failed Login Attempts parameter Craig Ringer <craig@2ndQuadrant.com>
2012-11-15 09:32 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
@ 2012-11-15 16:24 ` Craig James <cjames@emolecules.com>
2012-11-16 00:45 ` Re: Failed Login Attempts parameter Stephen Frost <sfrost@snowman.net>
0 siblings, 1 reply; 7+ messages in thread
From: Craig James @ 2012-11-15 16:24 UTC (permalink / raw)
To: Lukasz Brodziak <lukasz.brodziak@gmail.com>; +Cc: Craig Ringer <craig@2ndquadrant.com>; Frank Cavaliero <fcavalie@us.ibm.com>; 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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Failed Login Attempts parameter
2012-11-14 21:11 Failed Login Attempts parameter Frank Cavaliero <fcavalie@us.ibm.com>
2012-11-15 08:40 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 09:21 ` Re: Failed Login Attempts parameter Craig Ringer <craig@2ndQuadrant.com>
2012-11-15 09:32 ` Re: Failed Login Attempts parameter Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 16:24 ` Re: Failed Login Attempts parameter Craig James <cjames@emolecules.com>
@ 2012-11-16 00:45 ` Stephen Frost <sfrost@snowman.net>
0 siblings, 0 replies; 7+ messages in thread
From: Stephen Frost @ 2012-11-16 00:45 UTC (permalink / raw)
To: Craig James <cjames@emolecules.com>; +Cc: Lukasz Brodziak <lukasz.brodziak@gmail.com>; Craig Ringer <craig@2ndquadrant.com>; Frank Cavaliero <fcavalie@us.ibm.com>; pgsql-admin
* Craig James (cjames@emolecules.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
Attachments:
signature.asc (application/pgp-signature, 197B) download
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2012-11-16 00:45 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2012-11-14 21:11 Failed Login Attempts parameter Frank Cavaliero <fcavalie@us.ibm.com>
2012-11-15 08:40 ` Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 08:48 ` Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 09:21 ` Craig Ringer <craig@2ndQuadrant.com>
2012-11-15 09:32 ` Lukasz Brodziak <lukasz.brodziak@gmail.com>
2012-11-15 16:24 ` Craig James <cjames@emolecules.com>
2012-11-16 00:45 ` Stephen Frost <sfrost@snowman.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox