[tac_plus] Re: bad password/ban

[Schmidt, Daniel]

I was also concerned with this, yet was satisfied with the trade off.
It is also a feather in the cap against those who rail, "We need to dump
this open source thing and get a real Cisco Tacacs server!" 

As for a coworker doing a DOS attack, would that not result in immediate
dismissal at most places of employment?  Perhaps banning by IP, instead
of username, as fail2ban does would prevent this. 

There are a hundred ways you can accidentally get locked out with
tac_plus.  This would merely be one more, and it is an option that is
off by default.  Have a look at the code, it *looks* to be well thought
out.  

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Mark Ellzey Thomas
Sent: Monday, June 08, 2009 10:19 PM
To: john heasley
Cc: Mehrdad; tac_plus at shrubbery.net
Subject: [tac_plus] Re: bad password/ban

On Mon, Jun 08, 2009 at 08:12:46PM -0400, john heasley wrote:
> As I mentioned before, my problem with this is that it can be used as
a DOS.
> your co-worker could lock you out.  right?  i have no suggestions of
how to
> deal with that problem properly.

Yeah, I totally see where you are coming from. In my mind the risk is a
trade-off. Office antics like locking out your coworkers account would
result 
in even more evil retaliation at our place of work :)  

>From the perspective of a security engineer - it is much better to have
a
single user be a little annoyed that their account is locked temporarily

than to have their account compromised due to a brute force.  

Still, the concept of temporarily disabling accounts due to excessive
failures is not a new idea. Many authentication systems implement such
mechanisms, and many industry type audits require such features. 
It's also a nice failsafe when all of your staff who monitor such
events are home and in bed. 

Maybe a more solid approach is to further modify this patch so that you
can optionally disable account based on user/client-addr (as suggested
by others in this thread). The extra space is negligible and probably a 
good idea in the long run. 

_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus