Just a comment on our experiences with LDAP server delays on failed bind attempts.
We have encountered issues with applications when there is a delay between
failed attempts.
When there is an delay, the application is left waiting for a response from
the server.
This was the case with Novell's eDirectory for many years, there was a fixed
delay, and due to this condition, Novell added a feature to make the delay
adjustable.
If the delay is 3 seconds and five people in a row fail there password, the
application can only handle 5 people in 15 seconds, which is an eternity in
our context.
If the return code is returned immediately, then the application can end the
LDAP session immediately and move on to the next operation.
-jim
Jim Willeke
On Wed, Jun 30, 2010 at 4:28 PM, Kurt Zeilenga <Kurt.Zeilenga@isode.com
<mailto:Kurt.Zeilenga@isode.com>> wrote:
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 <mailto:Ldapext@ietf.org>
> https://www.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org <mailto:Ldapext@ietf.org>
https://www.ietf.org/mailman/listinfo/ldapext