Clowser, Jeff wrote:
- Consider this example - the place I run into this most
often is our
Internet proxies, which are password protected. There are
many apps a
user uses that connects through the proxy (which in turn
ldap) to get some kind of content or update. Some of these (broken) apps provide users an option to save the password, and when
they do (not
that I recommend this behavior, but I can't stop them), it tries repeatedly to get updates/content using the old password
after a user
changes their password.
I don't understand the problem: If the proxy is correctly implemented it will only send exactly *one* authentication request to a user database even if there are several parallel outstanding HTTP requests to be served by the proxy. If your proxy does not serialize authentication requests and then cache authentication state then fix your proxy.
The proxies cache *successful* authentication requests.
From a security POV, to suggest that "fixing" them is to cache
unsuccessful authentication requests (i.e. failed logins) actually *supports* this idea rather than refutes it. You're just suggesting doing the same thing at the proxy that was suggested to be done at the directory - if you're gonna do this, may as well help the entire enterprise instead of just some small part of it. Another disadvantage of doing it at the proxy is that you never see the failed binds at the centralized auth service (the ldap server), so have no central log of the true number of failed attempts. (In the mozilla ppolicy, even if a failed bind is ignored for lockout purposes, I believe it still logs the failed attempt).