Weak passwords and brute force attacks

Поиск
Список
Период
Сортировка
От Gavin Sherry
Тема Weak passwords and brute force attacks
Дата
Msg-id Pine.LNX.4.58.0612060019060.29303@linuxworld.com.au
обсуждение исходный текст
Ответы Re: Weak passwords and brute force attacks  (Andrew Dunstan <andrew@dunslane.net>)
Re: Weak passwords and brute force attacks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: Re: Order of checking for readline support libraries
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Postgres95 archives in mbox format