Re: [ldapext] password policy: delayed failures

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

On Jun 30, 2010, at 8:35 AM, Kurt Zeilenga wrote:

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

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


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