RE: password policy - alternate lockout mechanism

["Clowser, Jeff" <jeff_clowser@fanniemae.com>]

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

 - Jeff