[OPEN-ILS-DEV] Self-serve password reset thoughts

[Sharp, Chris]

Dan and Bill,

PINES would be very interested in this functionality as well.  Bill, are your modifications shared somewhere?  We'd love to test it out!

Thanks,

Chris

Chris Sharp
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, Georgia 30345
(404) 235-7147
csharp at georgialibraries.org
http://pines.georgialibraries.org/

----- "Bill Ott" <bott at grpl.org> wrote:

> On 3/28/10 6:36 PM, Dan Scott wrote:
> > I had a few minutes to pull together some thoughts on what we might
> want
> > from a self-serve password reset service and how it would be
> implemented
> > relatively securely at
> >
> http://evergreen-ils.org/dokuwiki/doku.php?id=dev:proposal:self_serve_password_reset
> This feature is something that is highly desired in our consortium,
> and I think it is something that should be supported out of the box.
> Our circ staff are tired of resetting passwords!
> >
> > One thing I noted is that actor.usr.email does not have a unique
> > constraint on it - presumably because a given set of users might
> share a
> > single email account (spouses or a family are the likely cases that
> > spring to mind).
> >
> > This complicates things considerably on the self-serve end, as my
> > current thoughts didn't account for this. I'm tempted to initially
> > disable self-serve password resets for accounts that don't have a
> unique
> > email address, because of the possible hilarity that could ensue if
> > account #1 issued a reset request for account #2, knowing that they
> > would be able to intercept the email with the password reset link.
> >
> > I'm certainly interested in feedback on these initial thoughts about
> a
> > self-serve password reset service. I'm hoping to have the time to
> > implement this over the next few weeks, if I can carve out the time
> from
> > other duties :)
> >    
> 
> 
> Ours is not quite as complex, but has been serving us well since we
> put 
> it into production 18 months ago.
> 
> We simply accept a barcode and email address.  If they match a given 
> account, the password is reset to a random 5-digit integer, which is 
> emailed to the address.  The email of course does not contain a
> barcode 
> or username, nor a link or any indication of where the password is to
> be 
> used, so the receiving party would need to already have that
> information 
> for it to be of use.  Because the value does not meet our complexity 
> requirements, it must then be reset by the user following the first
> login.
> 
> The most common complaint comes from individuals that do not have a 
> current email address in their account, and therefore cannot get the 
> form to reset their password.