[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] password policy: delayed failures
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.
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/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext