Re: Brute force credentials protection

[Brad Judy <brad.judy () CU EDU>]

While I generally agree with the article’s notes and Randy’s thoughts (with that big caveat about regulations), I am 
going to be cheeky and rephrase one of Randy’s items (because I know him well enough to give him a hard time)…

“Account lockouts encourage DOS attacks … We haven’t been hit by such an attack in 20 years.”

I hear the concern over account DOS attacks noted regularly, but I also last saw one around 2001. And that one wasn’t 
really intentional, it was the side-effect of poorly coded Windows worm malware. In terms of business interruption, I 
think accident account DOS fits into high likelihood with low impact (because it’s one user at a time) and intentional 
account DOS probably fits into low likelihood with high impact.

Is it a potential vector for disruption? Sure. But how much should it factor into the risk balance discussion for this 
topic? I’m not sure.

Brad Judy

Information Security Officer
Office of Information Security
University of Colorado
1800 Grant Street, Suite 300
Denver, CO  80203
Office: (303) 860-4293
Fax: (303) 860-4302
www.cu.edu<http://www.cu.edu/>

[cu-logo_fl]


From: EDUCAUSE Listserv <SECURITY () LISTSERV EDUCAUSE EDU> on behalf of randy <marchany () VT EDU>
Reply-To: EDUCAUSE Listserv <SECURITY () LISTSERV EDUCAUSE EDU>
Date: Tuesday, March 5, 2019 at 11:17 AM
To: EDUCAUSE Listserv <SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Brute force credentials protection

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<mailto: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!