Re: password policy - alternate lockout mechanism
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?
When you get to the general case of 'N' the feature being discussed here is no
longer relevant. The original hypothesis is that only a cracker will use N
different passwords on N different login attempts. If a legitimate user is
using N different passwords on N tries, then the hypothesis fails and there is
no validity to this feature at all.
If in fact a legitimate user only tries with 1 password, repeatedly, then
storing (a hash of) only the last attempted password will be sufficient to
detect this.
If you're storing only 1 password, and a cracker is attempting to break in at
the same time that the user is trying to login, then you might as well allow
the lockout to occur, because it will get a sysadmin's attention and they need
to respond to the attack anyway.
I think you'd have to store a hash
of all failed passwords tried within the window of time defined.
Since there is already a counter for maximum number of failed attempts, the
timestamp is superfluous.
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.
Removal should only occur when a successful login occurs. There's no need for
a separate expiration period.
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.
Making security-related suggestions that you haven't fully thought through yet
really isn't a good idea.
If you only allow pwdMaxFailure attempts before locking the account, there's
no point in even examining any passwords subsequent to the lockout event. So
no, there should never be a need to store more than pwdMaxFailure values.
But again, the point of this discussion is that when a legitimate user is
trying to login, you shouldn't need to recognize more than 1 bad password anyway.
Ultimately I believe the original hypothesis is invalid, and this whole
discussion is moot.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/