Making vt-password Spring-friendly

[Stephen Crawley]

Hi,

I'm currently trying to use vt-password as a password quality checker
in a Spring / SpringSecurity based project. Essentially, I'm trying
to configure the password rules using Spring XML bean wiring, and then
use them in a webapp to check new passwords when a user tries to set /
change his or her password. In doing this, I ran into some problems:

* Aspects of the APIs for the password rule classes make it awkward
to instantiate them using Spring wiring. Specifically, some classes
don't have no-args constructors. Some attributes don't have setters
that are compatible with the Java Beans conventions; e.g. we have
"void ignoreCase()" instead of "void setIgnoreCase(boolean)".

* The rule objects (surprisingly!) have attributes that are updated
when you check a password; the "message" attribute for all
PasswordRule classes and the "word" attribute (IIRC) of a
PasswordDictionaryRule. This means that I cannot instantiate one set
of rule objects at servlet startup and then use them in any request
thread each time a controller needs to check a password.

* The Dictionary class is very memory hungry. It loads the entire
dictionary into memory and constructs a heavy-weight tree structure.
I tried loading an "average" sized dictionary (~500,000 words) and ...
OOME. This may be OK if you are going to check 10's of passwords a
second. But in my use-case, I might see 1 password check an hour, so
tying down lots of memory is ... um ... wasteful.

I've uploaded a patch to the Issues Tracker to address the first two
points. It contains backwards compatible API changes to add
constructors, getters and setters, and a backwards compatible API
change to allow a "clean" copy of a rule to be made. It also extends
the DictionaryPasswordRule to check for exact word matches, and fixes
a bug (IMO) in the way the validate methods handled null Password
arguments.

I've also created an issue for the Dictionary problem, but the (IMO)
best solution ... to support multiple dictionary implementations ...
entails an API breaking change.

-- Steve

P.S. I'm using the code in the Emmet component we are writing for the
Atlas of Living Australia. The component's Maven site is at
http://metadata.net/sites/emmet-0.4-SNAPSHOT/

[Daniel Fisher]

On Sun, Jul 11, 2010 at 7:19 PM, Stephen Crawley <crawley...@gmail.com> wrote:

Hi,

I'm currently trying to use vt-password as a password quality checker
in a Spring / SpringSecurity based project.  Essentially, I'm trying
to configure the password rules using Spring XML bean wiring, and then
use them in a webapp to check new passwords when a user tries to set /
change his or her password.  In doing this, I ran into some problems:

I'm certainly interested in supporting a library that works with Spring.
To that end we'll work with you to ensure compatibility.
 

 *  The rule objects (surprisingly!) have attributes that are updated
when you check a password; the "message" attribute for all
PasswordRule classes and the "word" attribute (IIRC) of a
PasswordDictionaryRule.  This means that I cannot instantiate one set
of rule objects at servlet startup and then use them in any request
thread each time a controller needs to check a password.

A better solution here may be an event listener, but I'm open to ideas.

--Daniel

[Stephen Crawley]

On Jul 12, 11:27 am, Daniel Fisher <dfis...@gmail.com> wrote:
> >  *  The rule objects (surprisingly!) have attributes that are updated
> > when you check a password; the "message" attribute for all
> > PasswordRule classes and the "word" attribute (IIRC) of a
> > PasswordDictionaryRule.  This means that I cannot instantiate one set
> > of rule objects at servlet startup and then use them in any request
> > thread each time a controller needs to check a password.
>
> A better solution here may be an event listener, but I'm open to ideas.

The "solution" that I've come up with is to copy the rules objects and
use
the copies to do the validation. It is simple, and it works.

(This approach / solution doesn't work with rules that require context
apart
from the password; e.g. PasswordUserIDRule and PasswordHistoryRule.
I'd instantiate those rules immediately prior to validation using
request
specific context extracted by the controller.)

IMO, the ideal solution would be to have the `validate` methods return
an
object that contains the problem description and other information.
The event
listener pattern is for situations where you need to decouple event
consumers
from the event source. We don't need that here.

Incidentally, I've temporarily checked my hacked copy of vt-password
into
my project's SVN so that I can continue to make progress, and my
downstream
folks can build. I'd like to get rid of this ... so I'd be grateful
if you could review
and (hopefully) commit the patches I sent you. Also please consider
the issue
of pushing your artifacts to Maven Central.

Thanks,

-- Steve

[Daniel Fisher]

On Sun, Jul 11, 2010 at 11:43 PM, Stephen Crawley <crawley...@gmail.com> wrote:

On Jul 12, 11:27 am, Daniel Fisher <dfis...@gmail.com> wrote:
> >  *  The rule objects (surprisingly!) have attributes that are updated
> > when you check a password; the "message" attribute for all
> > PasswordRule classes and the "word" attribute (IIRC) of a
> > PasswordDictionaryRule.  This means that I cannot instantiate one set
> > of rule objects at servlet startup and then use them in any request
> > thread each time a controller needs to check a password.
>
> A better solution here may be an event listener, but I'm open to ideas.

The "solution" that I've come up with is to copy the rules objects and
use
the copies to do the validation.  It is simple, and it works.

I'm going to commit your patch as a thread safe solution for 2.x.
I have a few follow-up questions that I'll post in the issue.

--Daniel