Re: brute force attacking the password
От | Wim Bertels |
---|---|
Тема | Re: brute force attacking the password |
Дата | |
Msg-id | 42678890.3020109@khleuven.be обсуждение исходный текст |
Ответ на | Re: brute force attacking the password (Bruno Wolff III <bruno@wolff.to>) |
Ответы |
Re: brute force attacking the password
|
Список | pgsql-admin |
Bruno Wolff III schreef: >On Tue, Apr 19, 2005 at 22:54:32 +0200, > Wim Bertels <wim.bertels@khleuven.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. > > 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)
В списке pgsql-admin по дате отправления: