Subject: Re: [ldapext] password policy: delayed failures

From: Jim Willeke <[email-masked]>
Date: Thu, 1 Jul 2010 06:28:05 -0400

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

---

From: Howard Chu <[email-masked]>
Date: Thu, 01 Jul 2010 03:53:34 -0700

Jim Willeke wrote:
> Just a comment on our experiences with LDAP server delays on failed bind attempts.
>

Part of the problem is that LDAP lacks any means of distinguishing client 
requests from server requests. Ideally we would have a Bind variant that can 
be used in an already authenticated session that simply checks credentials, 
but doesn't alter the session's already established credentials. Then 3rd 
party apps that routinely perform authentication on behalf of other users 
could use this new Bind mechanism and deal with the failures themselves.

In the absence of such a DSP-style Bind, we can still use Compare operations. 
This is the approach we're taking to link SASL Binds to ppolicy, and also to 
manage ppolicy when Samba uses an LDAP backend. But as a general solution it's 
still pretty poor. (In both the SASL and Samba case, the credential is fully 
evaluated outside the directory. The result is reflected back into the ppolicy 
machinery by using the Compare operation with ppolicy control attached. When 
the credentials match, the Compare uses the current value of the userPassword 
attribute in its assertion, so that the ppolicy state machine will record a 
successful authentication. When the credentials don't match, the Compare uses 
some bogus value, so that ppolicy will record a failure.)

Also, features like this are obviously optional. If you have a directory 
server that is routinely being used by applications, then you probably want to 
isolate it from arbitrary clients, and not even deploy any lockout/delay 
features at all.
>
> -jim
> Jim Willeke
>
>
> On Wed, Jun 30, 2010 at 4:28 PM, Kurt Zeilenga <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     obvious DoS problems with account lockout, which delaying would help mitigate.
>
>      >> There needs to be a security consideration stated that server implementors
>     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.
>
>      > 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
>     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.
>
>      > 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
>      > issue here is that some (non-attack) clients might actually be designed to
>      > That sounds sensible, but I believe single attack per session is the
>     more common case, and these suggestions don't help there.
>
>      > different cases and hence lead to inappropriate disclosure of information.
>      >
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Jim Willeke <[email-masked]>
Date: Thu, 1 Jul 2010 09:08:51 -0400

-jim
Jim Willeke

> This is the approach we're taking to link SASL Binds to ppolicy, and also
> to manage ppolicy when Samba uses an LDAP backend. But as a general solution
> it's still pretty poor. (In both the SASL and Samba case, the credential is
> fully evaluated outside the directory. The result is reflected back into the
> ppolicy machinery by using the Compare operation with ppolicy control
> attached. When the credentials match, the Compare uses the current value of
> the userPassword attribute in its assertion, so that the ppolicy state
> machine will record a successful authentication. When the credentials don't
> match, the Compare uses some bogus value, so that ppolicy will record a
> failure.)
>
> server that is routinely being used by applications, then you probably want
> to isolate it from arbitrary clients, and not even deploy any lockout/delay
> features at all.
>

Unfortunatly, applications are nto created equally and usually the goal is
to use LDAP as the authentication source. As I see the recommendation,  this
would require pushing the Password (and Account Restriction) Policy
Enforcement Point to ALL the different applications which, IMHO, is not a
good thing and the implementation would woudl require that all applications
be capable of utilizing the same ability to perform the enforcement.

---

From: Howard Chu <[email-masked]>
Date: Thu, 01 Jul 2010 06:29:52 -0700

Jim Willeke wrote:
>
>
> -jim
> Jim Willeke
>
>
> On Thu, Jul 1, 2010 at 6:53 AM, Howard Chu <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Jim Willeke wrote:
>

>     server that is routinely being used by applications, then you probably
>     want to isolate it from arbitrary clients, and not even deploy any
>     lockout/delay features at all.
>
>
> Unfortunatly, applications are nto created equally and usually the goal is to
> use LDAP as the authentication source. As I see the recommendation,  this
> Enforcement Point to ALL the different applications which, IMHO, is not a good
> thing and the implementation would woudl require that all applications be
> capable of utilizing the same ability to perform the enforcement.

But that seems to ultimately be what you're asking for. "if the return code is 
returned immediately, then the application can end the LDAP session 
immediately" - so basically you want no restriction in the directory, and push 
the responsibility out to the application.

Or, you want a different policy for each application - which is feasible, if 
each application first authenticates as its own identity and then uses some 
"special" Bind to authenticate its client.

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 1 Jul 2010 06:47:04 -0700

On Jul 1, 2010, at 3:28 AM, Jim Willeke wrote:

> 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.

I noted this in my original comment and first followup, including providing two possible solutions.  I favor adding an "authenticate" extended operation.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 1 Jul 2010 06:50:53 -0700

> I noted this in my original comment and first followup, including providing two possible solutions.  I favor adding an "authenticate" extended operation.

Another approach would be to use a yet-to-specified chaining operation to chain the Bind request.

-- Kurt