Weak passwords and brute force attacks

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Weak passwords and brute force attacks
Date: 2006-12-05 13:50:24
Message-ID: Pine.LNX.4.58.0612060019060.29303@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

Host-based authentication and the other security mechanisms we have at the
moment provide fairly rigorous security but it seems to me there are two
mechanisms other authentication systems provide which we do not: testing
of the strength of passwords and delaying response after an authentication
failure.

The password strength test is pretty self-explanatory: DBAs often have to
hand out accounts to a range of real people who will be using anything
from reporting apps to testing new applications etc. With strength
testing, a DBA can at least ensure that a certain standard of complexity
is met. The attached patch adds two GUCs called 'test_weak_passwords' and
'min_password_length'. If 'test_weak_passwords', passwords will be
analyzed during CREATE and ALTER ROLE. It's not as simple the password
being greater than min_password_length. I guess the GUC name is a bit
confusing in that respect. Instead, what we do is add up the different
character types (lower, upper, digits, etc) and for each character type
missing, we reduce the hypothetical password length: the theory being that
the longer the password, the harder to guess.

Now, in the presence of encrypted passwords being sent across the wire, we
can't do anything. So, we export the password strength tester to libpq.

The second mechanism is the delay on authentication failure. The problem
here is that a distributed application could attempt to brute force guess
a password for a role. This could be fairly effective on a high speed LAN.
So, the usual approach is to delay sending the failure message to the
client for some period of time (specified in the patch by
auth_failure_delay) to slow the progress of the password guesser.
Naturally, environments where you cannot trust the local network sound
like problem outside out scope. But, I see a lot of systems with sensitive
company information (consider an HR system) which even employees should be
denied access to.

Authentication failure delay can be done with PAM but not everyone will be
abke to use PAM.

Any thoughts on these ideas?

Thanks,

Gavin

Attachment Content-Type Size
sec-3.diff text/plain 21.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-12-05 14:33:46 Re: Postgres95 archives in mbox format
Previous Message Simon Riggs 2006-12-05 13:10:00 FAQ refresh