Re: contrib: auth_delay module

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

In response to

Responses

Browse pgsql-hackers by date

  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