Subject: [ldapext] password policy: delayed failures

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 30 Jun 2010 08:35:06 -0700

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.

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.

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.

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

Another issue is 'resets on successful authentication'.  'resets on successful non-anonymous authentication' would be better.

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.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 30 Jun 2010 09:34:26 -0700

> 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, d…

I note that 'delay' of any sort will likely cause problems for these clients.  They are likely multiplexing multiple user interactions onto one LDAP session.  It would be better for them to the delay the user than for the LDAP server to delay responses to such clients.  But a server cannot distinguish such clients from other 'more normal' clients.

One could argue that such clients should be authenticating as themselves and then using some sort of operation to check the validity of user credentials, such as possibly an LDAP compare (yuk) or some LDAP extended operation (yet to be specified in an RFC).

-- Kurt

---

From: Howard Chu <[email-masked]>
Date: Wed, 30 Jun 2010 11:39:56 -0700

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

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

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

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

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

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 30 Jun 2010 13:28:43 -0700

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

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

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

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

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

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

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

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