[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, 10:16:46 schrieb 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/60616171e09cc24c63e899533e0280
>> >> > b7b 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
>>
>
> Hi Gunnar,
>
> I implemented a backend-independent implementation based on your message and
> I also read Jan's authentication articles on his blog. Maybe I was a bit too
> hurried the last few days.
>
> Now I conditionally inject and utilise horde_history for bad login counting
> and horde_lock for locking. I did not go for the decorator pattern though.
> There is the precendent of Horde_Log which is already injected into the Auth
> driver.
>
> http://git.horde.org/horde-
> git/-/commit/67f9ba8aa5c71b91c43a46974d4798b8023713d0
>
> I like this version much more and will drop the sql driver specific driver
> addon. Also means a few additional fields less in the horde config xml.

Great. Looks good, thanks!

Gunnar

>
> Thx
>
> Ralf
> --
> Ralf Lang
> Linux Consultant / Developer
>
> 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