[Date Prev][Date Next]
RE: password policy - alternate lockout mechanism
Aravind Gottipatu wrote:
>On Tue, Jan 27, 2009 at 9:28 AM, Howard Chu <email@example.com> wrote:
>> What makes you think a legitimate user who forgot their password
>> multiple times with different passwords? I.e., what makes you think
>> 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
How would you tell a legitimate user trying 20 different passwords from
that only tries 20 different passwords? You can't. If you feel 50
acceptable, because a real attack would quickly exceed that, why not set
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
Sounds like what you are saying is that rather than counting the number
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
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
out in detail) that there would be a gotcha to this - performance issue,
security vulnerability saving all those attempted passwords, etc.