[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Password policy: possible DoS scenario

Hello Buchan,

01.03.2011 13:29, Buchan Milne writes:
> On Tuesday, 1 March 2011 07:23:41 Konstantin Boyandin wrote:
>> Hello,
>> Thanks to everyone having answered me earlier, I've managed to set up
>> password policy on the OpenLDAP provided in CentOS 5.5 repositories
>> (current version 2.3.43).
>> The setup: we have password policy enabled for users accounts in our
>> intranet. After 5 unsuccessful attempts the account is blocked for short
>> duration (30 seconds).
>> Does that mean that anyone now can keep all the accounts blocked most of
>> the time?
> Well, you do the maths.
> But, surely you have enough monitoring in place that you would be able to 
> notice a high rate of unsuccessful binds, so that the duration of "most of the 
> time" would not be very long.

While I am talking of the intranet, I feel I am in control. Logs are
monitored and if  someone causes repetitive account lockouts, it's easy
to detect.

Problems can happen when there is need to open certain services from
outside (email, for example).

>> Am I right that if anyone enters someone else' incorrect
>> password 5 times (in the given case), they will block the target account
>> (regardless of what IP address the attacker was connecting from)?
> Yes. But, where is the line between a DoS and an attempt to break into an 
> account?
> In either case, if this *is* only in your intranet, behaviour like this would 
> surely violate your terms of use policy ...

Of course.

>> Narrower question: do password policy module developers plan to take
>> into account what IPs are used to connect (thus, blocking only access
>> from specific IPs)?
> Maybe you should provide a specific use case, besides "my users violate my 
> terms of use, and I can't do anything about it".

A typical use case is this. We make users change their passwords
regularly, password policy was introduced to further urge to use safer

Now imagine a person's email being checked regularly from outside the
intranet. After the specified attempts the account gets locked. The only
option we have in such a case is to firewall the address that sends
wrong credentials.

In case the locks are IP-bound, they would only affect those attempting
to gain access (regardless of whether those are legitimate or
unauthorized attempts).