[Date Prev][Date Next] [Chronological] [Thread] [Top]

[ldapext] password policy: delayed failures



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


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