RE: password policy - alternate lockout mechanism

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

Kurt Zeilenga wrote:
>On Jan 27, 2009, at 12:14 PM, Clowser, Jeff wrote:
>
>> That would be nice, but I can't help but think (without having
thought
>> it
>> out in detail) that there would be a gotcha to this - performance  
>> issue,
>> security vulnerability saving all those attempted passwords, etc.
>
>There is actually a significant security risk in keeping a history of  
>such passwords.  While they might be invalid at the DSA for  
>authentication, they are likely valid elsewhere. That is, it quite  
>likely that a user might enter passwords for related systems.  So  
>keeping long term (pass the authentication request) exposes the user  
>to greater risk.

My thinking exactly.  But then, if they are encrypted and protected 
the same as the password history and userpassword attributes, that 
might mitigate this particular risk to an extent, especially if you
sync your users passwords across all systems, as many corps do (Don't 
get me wrong, I still see this as risky and I can think of many ways 
it may be misused...)

>Of course, one should note that lockout mechanisms are a major target  
>of DoS attacks...

Without a doubt.  But... I think what Aravind was getting at was a way 
to reduce the potential for (particularly unintentional) DoS "attacks" 
- cases such as clients that store an old password and then lock out a 
user, etc.  We get tickets for that all day here as well...  Actually,
I'd say most if not all of out password lockout issues are from this
rather than genuine attacks, but we still have to implement password
policies like this "just in case" and follow up on each case (we're a 
rather prime target here...)

I will say that if such an enhancement *were* to be implemented, it 
would probably eliminate almost all our false positives and only lock 
out users for extreme cases and genuine attacks...

 - Jeff