[RADIATOR] Account Locking for Yubikey Authentication

[Heinz, Dave]

Heikki,

Thanks for your response. Yes, I have a Users table which references the
Yubikey table as well.
My locked flag would exist in the Users table.

>From our standpoint, if the user account fails login X amount of times in
a Y period, the account would be locked until an Admin unlocked it. Also,
if a successful login occurs prior to reaching X, then X and Y are reset
to 0. Any further failures after the account is locked are of course
logged, but not needed to be counted. Its my viewpoint (again, for my
purposes only) that an Admin would look at the logs to see if this was
just user error, or if there is some type of brute force happening and
make the decision to unlock the account or not.

In a generic sense when writing a module for this I think a config
variable indicating the behavior required would be warranted, perhaps
others would like it to unlock itself after Z time has passed. Maybe
someone would indeed like to see the continued failed attempts, etc..

I can certainly attempt to make this a PostAuthHook. I will let you know
how my progress goes. As for a Radiator feature, I¹ll let you decide that
one. I know there have been many instances over the years where something
like this would have been nice to have.

Dave Heinz



On 1/9/14, 11:35 AM, "Heikki Vatiainen" <hvn at open.com.au> wrote:

>On 01/08/2014 07:38 PM, Heinz, Dave wrote:
>> Security team for my company would like us to be able to lock an account
>> (tacacs in this case) in the event the user fails X times in Y minutes.
>> 
>> We use Yubikey for 2-factor authentication with the Radiator TACACS
>>server. 
>> 
>> Is there a way for it to flag an account and ³disable² the account
>> meeting the failed criteria? Would this have to be a ³feature² request
>> for the next version?
>
>Currently the Yubikey SQL DB holds information that is only directly
>related to Yubikey use. Any logic to lock the account would need to be
>implemented separately e.g., by a PostAuthHook or a specific module that
>does locking policy.
>
>If implemented by a hook, the information could go into the current
>Yubikey table. Required number of columns could be added to the table to
>hold the bad login count, timestamps and any other information the
>implementation needs. The hook then updates and maintains this
>information based on the AuthBy result and current time. However, this
>may not be enough depeding on the requirements. More about this later.
>
>A more generic approach could be to create a module that implements
>locking. It could be then used with the other AuthBys too, for example
>AuthBy FILE when stacked with a suitable AuthByPolicy.
>
>If you want to implement this yourself, I'd ask for a clear
>specification how the locking needs to be done. For example:
>
>Does your security team require that the account stays locked or should
>the lock be automatically cleared after a certain time has passed? Would
>a successful login clear failed attempts or is it strict, e.g., 5 bad
>logins within last 10 minutes no matter if there were good logins too.
>Also, if the bad logins continue during the lock down period, are they
>counted too?
>
>If this should be Radiator feature, we would most likely make it a
>generic SQL based module. Any comments related to this would be
>appreciated.
>
>Thanks,
>Heikki
>
>
>-- 
>Heikki Vatiainen <hvn at open.com.au>
>
>Radiator: the most portable, flexible and configurable RADIUS server
>anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
>NetWare etc.
>_______________________________________________
>radiator mailing list
>radiator at open.com.au
>http://www.open.com.au/mailman/listinfo/radiator