[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: password policy - alternate lockout mechanism
On Jan 28, 2009, at 3:43 PM, Aravind Gottipati wrote:
On Wed, Jan 28, 2009 at 2:52 PM, Kurt Zeilenga <Kurt@openldap.org>
wrote:
Why not just raise the max tries to, say, 100?
Because, that does not solve the problem. Here is an example. User A
may have used passwords P1, P2, P3 in the past and he may have a few
commonly used passwords P4 and P5 as well (that he uses for other
sites). Lets say P1 is the current password on the system. Lets say
MaxFailureAttempts is set to 100.
User A changed the password, but forgot to update the some
applications (some of which he doesn't use often). Some of these
applications may still be (storing and) using P2 or P3 even.
Sounds like these applications are broken.
In the current system, if one of these applications continues to try
to repeatedly login with any of P1 through P5 it will lock him out
after 100 attempts.
It seems these limits are giving you and your users far more pain than
they ever will give an attacker.
In the modified system, since he is only trying a
few of these P1, P2, P3 (or even P4 and P5), there is no reason to
lock him out. This is clearly not a crack attempt, since he is only
trying these few passwords multiple times.
At the expense of the directory exposing the user to more risk.
At the expense of more complexity in the directory (read, more risk).
At the expense of resources to save and managing this history (read,
more risk).
A crack attempt on the other hand will quickly run over
MaxFailureAttempts with different passwords.
Right, A DoS attacker will lock out the user regardless given any sort
of limit.
I logged a new bug in the ITS form, but it didn't spit back a bug
number at me.
It's there. It was published to -bugs. As to what happen to the
usual email to the submitter, I haven't a clue. Likely quarantined
somewhere (not here).
I outlined the scheme Jeff proposed earlier which would
probably work very well for a system like this.
Aravind.