Re: password policy: delayed failures

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 <[email protected]>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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ldapext
>
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext
>

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext