Bruno Wolff III schreef:
On Tue, Apr 19, 2005 at 22:54:32 +0200,
Wim Bertels <wim.bertels@xxxxxxxxxxx> 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.
indeed.
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
login/user)
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)
