[Date Prev][Date Next] [Chronological] [Thread] [Top]

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/