Skip site navigation (1) Skip section navigation (2)

Re: brute force attacking the password

From: Wim Bertels <wim(dot)bertels(at)khleuven(dot)be>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: brute force attacking the password
Date: 2005-04-21 11:03:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Bruno Wolff III schreef:

>On Tue, Apr 19, 2005 at 22:54:32 +0200,
>  Wim Bertels <wim(dot)bertels(at)khleuven(dot)be> wrote:
>>not an easy problem: it always seems to end up in DoS vs Brute Force Cracking.
>>So the only good and simple solution i can think of: use the best possible  
>>password encrytion (or sufficient, a statistically zero chance when trying as 
>>much connections -to brute force crack the password- as possible for a 
>>significant amount of time.)
>Maybe you can use client side certificates. Those will be from a large
>enough space that guessing shouldn't be a problem. You should be able to
>make that work with PAM.

since brute force attacks are quit traceable (targetting one and the 
same user eg..),
one could a script to check:
- the percentage of failed logins/user, depending on the percentage (eg 
75% or more failed, this should be configurable), these events should be 
reporteg in security.log file under the postgres log directory, or 
mailed to user (inetd...)
- if there are more than eg 10 (this should be configurable) failed 
consecutive logins/user, this should again be reported.

if i have time: maybe a quick perl script using the postgres.log file 
with sufficient logging to obtain these facts?

so: possible implementation so far:
1. choose the possible crypting for the password
2. implement someway the above checking (% failed logins/user + < failed 
3. using client side certificates with pam, pam_ldap (not sure how to 
set this up right know, a certificate/user (having many users, not all 
specialists,..., how to make this work a user-acceptible way..); or just 
a few (or 1) client side certificates that can be used by many users 
(sounds more easy, accessible to set up for the users)

In response to


pgsql-admin by date

Next:From: Spiegelberg, GregDate: 2005-04-21 13:09:06
Subject: Re: delete to slow
Previous:From: Jim C. NasbyDate: 2005-04-21 04:09:57
Subject: Re: cost of empty fields

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group