Re: password policy: delayed failures

-jim
Jim Willeke


On Thu, Jul 1, 2010 at 6:53 AM, Howard Chu <[email protected]> wrote:

> Jim Willeke wrote:
>
>> 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.
>>
>
> 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.
>

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.

>
>> -jim
>> Jim Willeke
>>
>>
>> On Wed, Jun 30, 2010 at 4:28 PM, Kurt Zeilenga <[email protected]
>> <mailto:[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] <mailto:[email protected]>
>>
>>     > https://www.ietf.org/mailman/listinfo/ldapext
>>
>>    _______________________________________________
>>    Ldapext mailing list
>>    [email protected] <mailto:[email protected]>
>>
>>    https://www.ietf.org/mailman/listinfo/ldapext
>>
>>
>>
>
> --
>  -- 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