Why not just raise the max tries to, say, 100?
-- Kurt
On Jan 28, 2009, at 2:28 PM, Clowser, Jeff wrote:
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