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

Re: [ldapext] password policy: delayed failures

On Jun 30, 2010, at 11:39 AM, Howard Chu wrote:

> Kurt Zeilenga wrote:
>> I'm updating Isode's password policy implementation and have a few
>> thoughts
> on the ppolicy I-D that might be worth some discussion. I'll post each issue
> in a separate thread...
>> 
>> This message discusses delaying authentication failures
>> 
>> This seems something not terribly specific to password-based
>> authentication
> so not clear it really belongs in the password policy.
> 
> Maybe not. The reason it's been brought up here is because the account lockout feature is already in the password policy draft, and there are obvious DoS problems with account lockout, which delaying would help mitigate.

I recall noting that account locking should be separated as well...

I'm not sure how delaying bind failures significantly mitigates account lockout DoS attacks.  That is, so an attack takes a few more seconds, not much mitigation there.  Or am I missing something?

> 
>> There needs to be a security consideration stated that server implementors
> need to take precautions to avoid creating DoS attack vectors when
> implementing delayed responses.
> 
> Is that really a security consideration? That's like saying server implementors need to take precautions against SEGV when implementing something.

It's fairly typical for RFCs to note specific instances where care might be taken, especially where the instance is non-obvious.  This might well be viewed as obvious and one could argue the reader's limited attention should be consumed by more significant concerns.

I'm fine with leaving inclusion of such a consideration to your and your co-authors discretion.


> 
>> It's not clear whether by "first failed authentication attempt" is per
> session or per account. If per account, I think there's a problem that there's
> no state mechanism for non-accounts. A non-account would likely get a flat
> delay (the minimum). The difference in delay could be used by an attacker to
> determine which accounts existed or not. Per session might be more sensible.
> 
> That's a good point about non-accounts. But I don't see how per-session will be of much use; the password attacks I see against my machines come from multiple IP addresses at once, and frequently a single IP address is only used once in any given attack incident.

Well, I think where a delay is useful, a flat delay is good enough.

I've been considering a number of attacks scenarios, some based on what I've seen against actual LDAP services, some I've seen against other services (such as web, ssh services), and some just considering how I would mount such an attack if I was so inclined.   In many of these scenarios, the delay seems to be little hinderance to the attack.

One interesting thing to note that if one's site were getting hit by a brute force attack where one session one used per session, by turning on a delay, the brute force attack will likely become a service DoS attack (independent of the attacker's intent).

>> To defend against brute force attack within a single session, I think it
>> be
> better for servers to implement a few basic things than deal with delay (which
> often open to DoS attack vectors). One, detect improper pipelining of Bind
> requests and drop session if that's the case. Two, have the server limit the
> number of consecutive password-based Bind failures allowed on session. An
> issue here is that some (non-attack) clients might actually be designed to
> improper pipelining and/or do only bind requests (such as an client providing
> authentication services for some application).
> 
> That sounds sensible, but I believe single attack per session is the more common case, and these suggestions don't help there.

Does the delay actually hinder the most common cases? 

I think we need to worry more about the sophisticated attack, as they will become common eventually.

> 
>> Another issue is 'resets on successful authentication'. 'resets on
> successful non-anonymous authentication' would be better.
> 
> We can say that but I'm not sure it's a valid distinction. E.g., password-less Binds succeed, but they do not authenticate.

Well, I wasn't trying to split hairs here.   My point is more that without qualification it likely that some implementor will reset on any successful Bind.

>> Personally, I think the min/max stuff is overly complicated. I think a
> simple flat delayed response is for than sufficient to hinder brute-force
> attack and doesn't suffer from the risk that different delays could be tied to
> different cases and hence lead to inappropriate disclosure of information.
> 
> OK. It's a valid point, and we may need to scrap the min/max stuff. Alternatively, it could be per-session instead of per-account, but I think per-session controls are of very limited usefulness.

I favor a flat delay.

> 
> -- 
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext