Re: Brute force credentials protection

[randy <marchany () VT EDU>]

If you have strong password requirements, log failures/success and aren't
bound by a specific regulation/law, IMHO, disable account lockouts. Why?
IMHO,
1. Account lockouts are a 45 year solution to password guessing. In those
days, Unix didn't have any password strength mechanisms. Later, tools like
npasswd, passwd+ provided that capability and not until ~1992 with IBM's
AIX 3.1 did any Unix system come with builtin password strength settings.
Times have changed.
2. Strong password requirements, MFA, logging are more than adequate to
deal with brute force attacks.
3. Account lockouts encourage DOS attacks by simply scripting multiple
logins with dumb passwords. The goal, of course, is not to get access to
your account but to deny you access to your account. This is nothing new.
We were hit with such an attack in 1999 which forced to drive to the data
center to deal with the issue.
4. Do you notify the offending site that you're being brute forced from
them? While this can be tedious, it's also good neighbor policy.

Of course, if a reg/law requires you to keep lockouts enabled, nothing you
can do about that.
Don't create a worse problem than the one you were trying to solve. :-)

Just my .02.

Randy Marchany
VA Tech IT Security Office and Lab


On Tue, Mar 5, 2019 at 1:05 PM Mike Dronen <
mike.dronen () minnetonkaschools org> wrote:

> Phil's article was quite interesting - we'll be discussing it at our
> weekly security meeting. While we've not had significant account lock-out
> issues in our environment - combined with our password policy it makes
> sense to slightly increase our failed attempt number...then again.... As
> for a perimeter tool, interesting as well - though it seems in EDU (student
> curiosity) we are protecting assets as much from the outside as the inside.
> I really appreciate all the insights!