RE: password policy - alternate lockout mechanism

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

>> Also, I am not sure how this will be any greater security risk than
>> the current system of storing a SSHA hash of the current password
>> within LDAP?  We could store similar hashes of all the passwords
tried
>> (upto pwdMaxFailure) and compare against that?
>
>I'm wondering if that's even necessary. According to your description
so far, 
>it would be sufficient to only store 1 failed password. If as you say,
the 
>same password is tried multiple times, then this should be good enough.

The caveat to this is that if you have two or three or N different
passwords tried (one by an app that has the old password, one 
because of a fat finger mistake, etc in no particular order), how 
do you know which one to store?  I think you'd have to store a hash 
of all failed passwords tried within the window of time defined.

I'm thinking the values would look something like:

<timestamp>;{<scheme>}<hash>

The timestamp would be the most recent time this was seen,
scheme is crypt/sha/ssha/etc matching whatever is in the 
userpassword attribute, and hash is the encrypted password.

If the number of values in this attribute exceed the number 
of max fails allowed, the account is locked.  Timestamp is
needed to eventually expire and remove it.

The problem I would be concerned about is if this was really
under a brute force attack, the number of values in this attribute
could grow very quickly.  Would it be reasonable to only store
the last pwdMaxFailure passwords tried?  I think maybe it would,
but haven't really thought it through yet.

Jeff