Educause Security Discussion mailing list archives

Re: Brute force credentials protection


From: Greg Williams <gwillia5 () UCCS EDU>
Date: Wed, 6 Mar 2019 15:30:57 +0000

We implemented it.  Works well. We will be talking about many Microsoft security offerings in our session at SPC in May 
if anyone is interested.

Greg Williams, ME
Director of Operations
Office of Information Technology
University of Colorado Colorado Springs
1420 Austin Bluffs Parkway, (EPC 136A)
Colorado Springs, CO 80918
Phone: (719) 255-3292
www.uccs.edu<http://www.uccs.edu/>

From: The EDUCAUSE Security Community Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU> On Behalf Of Tom Horton
Sent: Tuesday, March 5, 2019 11:33 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Brute force credentials protection

We've begun the process of deploying ADFS Smart Lockouts. Like the old lockout policies, but with a bit of baseline 
anomaly detection and machine learning built in.

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-server%2Fidentity%2Fad-fs%2Foperations%2Fconfigure-ad-fs-extranet-smart-lockout-protection&data=02%7C01%7Cgwillia5%40UCCS.EDU%7C7a9097afb6fd41ef1dcd08d6a1990248%7C529343fae8c8419fab2ea70c10038810%7C1%7C0%7C636874075877142567&sdata=lYZ1yQpEV%2FYXF7bffW2SXuMPSNl0x%2Ba9g660G1RFY1E%3D&reserved=0>

It shows a lot of promise for protecting against brute force attacks *and* the DoS ramifications of a typical account 
lockout policy. If there's interest, I'll keep you all posted on progress and lessons learned.

-Tom


Tom Horton

Acting Chief Information Security Officer

Assistant Director for Identity Management and Security Engineering

Cornell University

IT Security Office

120 Maple Ave.
607-255-7582
________________________________
From: The EDUCAUSE Security Community Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV 
EDUCAUSE EDU>> on behalf of Brad Judy <brad.judy () CU EDU<mailto:brad.judy () CU EDU>>
Sent: Tuesday, March 5, 2019 1:28 PM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Brute force credentials protection


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<mailto:SECURITY () LISTSERV EDUCAUSE EDU>> on behalf of 
randy <marchany () VT EDU<mailto:marchany () VT EDU>>
Reply-To: EDUCAUSE Listserv <SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>>
Date: Tuesday, March 5, 2019 at 11:17 AM
To: EDUCAUSE Listserv <SECURITY () LISTSERV EDUCAUSE EDU<mailto: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!


Current thread: