From: | Jan Urbański <wulczer(at)wulczer(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Subject: | Re: contrib: auth_delay module |
Date: | 2010-11-04 13:13:34 |
Message-ID: | 4CD2B17E.6090500@wulczer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/11/10 14:09, Robert Haas wrote:
> On Thu, Nov 4, 2010 at 6:05 AM, Itagaki Takahiro
> <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
>> 2010/11/4 KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>:
>>> The attached patch is a contrib module to inject a few seconds
>>> delay on authentication failed. It is also a proof of the concept
>>> using the new ClientAuthentication_hook.
>>>
>>> This module provides a similar feature to pam_faildelay on
>>> operating systems. Injection of a few seconds delay on
>>> authentication fails prevents (or makes hard at least) brute-force
>>> attacks, because it limits number of candidates that attacker can
>>> verify within a unit of time.
>>
>> +1 for the feature. We have "post_auth_delay" parameter,
>> but it has different purpose; it's as DEVELOPER_OPTIONS
>> for delay to attach a debugger.
>>
>> BTW, the module could save CPU usage of the server on attacks,
>> but do nothing about connection flood attacks, right?
>> If an attacker attacks the server with multiple connections,
>> the server still consumes max_connections even with the module.
>
> Hmm, I wonder how useful this is given that restriction.
As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie
consuming), right?
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-04 13:16:45 | Re: Comparison with "true" in source code |
Previous Message | Robert Haas | 2010-11-04 13:09:09 | Re: contrib: auth_delay module |