[dev] On authentication locking and bad login count Re: [commits] Horde branch master updated. 60616171e09cc24c63e899533e0280b7b1f4c064

[Gunnar Wrobel]

Quoting Ralf Lang <lang at b1-systems.de>:

> Am Montag, 15. August 2011, 05:00:10 schrieben Sie:
>> > account locking for Horde_Auth_Sql
>> >
>> > -----------------------------------------------------------------------
>> >
>> > commit 60616171e09cc24c63e899533e0280b7b1f4c064
>> > Author: Ralf Lang <lang at b1-systems.de>
>> > Date:   Fri Aug 12 14:37:29 2011 +0200
>> >
>> >     [#10387] Draft implementation of bad login counting and account
>> >
>> > locking for Horde_Auth_Sql
>> >
>> >  framework/Auth/lib/Horde/Auth/Base.php |    2 +-
>> >  framework/Auth/lib/Horde/Auth/Sql.php  |  169
>> >
>> > ++++++++++++++++++++++++++++++-
>> >
>> >  2 files changed, 164 insertions(+), 7 deletions(-)
>> >
>> > http://git.horde.org/horde-git/-/commit/60616171e09cc24c63e899533e0280b7b
>> > 1f4c064
>>
>> We had something something similar for a while in the Kolab auth driver.
>>
>> http://git.horde.org/co.php/framework/Auth/Auth/Attic/kolab.php?rt=horde&sa
>> =1&ws=1&r=1.32
>>
>> That one used the History system for the "bad login count" though.
>> Wouldn't that be the better option? The "bad login count" could work
>> for all drivers rather than just the SQL driver. And it could be used
>> for a simple time-based lockout if an Auth driver does not support
>> locking. If a driver supports locking the additional capability could
>> be used.
>>
>
> Great hint, thank you.
> The history can gradually "forget" about single bad logins, which  
> the auth_sql
> implementation can't.
> I also thought about using horde_lock for generalizing the locking bit.

Yup, sounds good as well. Though it should probably still be allowed  
for a specific driver to provide its own locking scheme.

>
> However I did not find a good solution:
> * We do not use singletons anymore.

Which is indeed a very good thing :)

> The history and/or lock instance needs to
> be injected (which I think should not happen on library level) or passed.

I lack the time to look at the code at the moment. But I don't think  
this needs to live in Horde_Auth itself. I would assume it is possible  
to add the History integration either as an authentication Hook or as  
a complete Decorator to Horde_Auth that only gets applied in case the  
admin activated the "bad login tracking". Just rough ideas though...

> * I have some pending research if ldap/AD provide account locking schemes and
> if they are widely used. Specific drivers could override default locking
> scheme though
>
> * I was not happy about adding more dependencies to Horde_Auth but passing
> them in the constuctor may be OK.

See above. Tracking the number of bad logins seems to be a purely  
decorative addon to the authenticate() method.

Cheers,

Gunnar

>
> I see if I can put up something general which doesn't break existing stuff.
>
> --
> Ralf Lang
> Linux Consultant / Developer
> Tel.: +49-170-6381563
> Mail: lang at b1-systems.de
>
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de