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

[Ralf Lang]

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.

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