Aravind Gottipatu wrote:
On Tue, Jan 27, 2009 at 9:28 AM, Howard Chu hyc@symas.com wrote:
What makes you think a legitimate user who forgot their password
won't try
multiple times with different passwords? I.e., what makes you think
you can
distinguish a cracker from a legit user this way?
True, a legitimate user that has forgotten their password will try multiple times with different passwords. However it's still a small set of different passwords they would be trying. Contrast that with a crack attempt where someone would try with a different password every time. Let's say that we set the limit at 50. Its unlikely that a legitimate user would try with more than 50 different passwords. They'd just give up after some small number and file a ticket to have it reset. A crack attempt on the other hand would easily cross that limit.
How would you tell a legitimate user trying 20 different passwords from an attack that only tries 20 different passwords? You can't. If you feel 50 attempts is acceptable, because a real attack would quickly exceed that, why not set your policy pwdMaxFailure to lock after 50 failed attempts?
In our case, the usual problem has been that someone changes their password, they don't change their password on all the machines they use to access corp resources. So some mail client somewhere keeps trying to login with the same old password, and locks them out because the application doesn't have the sense to stop trying after a failed attempt.
Sounds like what you are saying is that rather than counting the number of failed attempts to bind, you want to count the number of failed unique passwords that were attempted - i.e. if you keep trying the same password over and over, it only counts as one, so clients with saved passwords don't constantly lock out accounts.
That would be nice, but I can't help but think (without having thought it out in detail) that there would be a gotcha to this - performance issue, security vulnerability saving all those attempted passwords, etc.
- Jeff