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.