[OPEN-ILS-DEV] ***SPAM*** Re: Self-serve password reset thoughts

[Bill Ott]

On 3/29/10 12:35 AM, Dan Scott wrote:
> On Sun, 2010-03-28 at 21:47 -0400, Bill Ott wrote:
>    
>> 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.
>>
>>      
> All bets are off when you're sending anything via email, I suppose.
>
> My concern about your approach is that attacks become pretty straight
> forward: you just need to know a user's user name (or barcode) + email
> address to reset their password to a 5-digit integer. In our context,
> these two pieces of information would be pretty easy to come by
> (consider two people that might have had a relationship go sour). Also,
> given the institutional nature of our Evergreen install, our users' user
> names tend to be their institutional email addresses, or the prefix part
> of their email address, so this combination is often predictable.
>    

It is for this reason that we require the barcode proper, the username 
is not accepted.

To a large extent, a compromised barcode is a pretty damning situation 
alone, as it's rather simple to replicate that barcode and use it at a 
self-check machine, walking away with potentially thousands of dollars 
worth of materials checked out to someone else.


> To illustrate why I'm implementing something along the lines of what I
> linked to, consider what could happen if someone malicious does have the
> user name or barcode + email address in hand.
>
> In the best case scenario, nothing happens and we're all happy. In
> reality, this is probably the vast majority of the cases that would
> occur.
>
> In a slightly worse scenario, however, a malicious user armed with this
> knowledge just annoys the heck out of the targeted user, as the victim's
> password could be reset continuously by simple manual requests on the
> part of the malicious user.
>
> In a slightly worse scenario, the malicious user would script the
> password reset request to occur every five minutes, effectively locking
> the victim out of their account. Even though the victim could request
> their own password reset, the malicious request will follow within the
> next five minutes, locking them out again.
>
> In a worse scenario, the malicious user combines the password reset with
> a brute force attack; now that the password strength has been reduced to
> a mere 99,999 combinations, the malicious user stands a pretty good
> chance of issuing the password reset request at some time when the
> victim is not paying attention to email (say, at 1:00 AM). If they then
> fire off one login attempt per half-second, they will have tested 50,000
> passwords in 6 hours. If they hit the right password, then they can
> change the victim's email address and password; as the email address has
> been changed, it prevents the victim from resetting their password
> without a visit or call to the circ desk (depending on library policy).
>
> Or more dire, if the malicious user access manages to log in, they can
> view the victim's contact information - which could have severe
> consequences if, say, the victim had moved to avoid the malicious user -
> then issue another password reset request. The victim just sees
> back-to-back "Your password has been reset" email messages and otherwise
> does not know what has happened.
>
> So, even though the cases where things go this sour are likely going to
> be few and far between, and once they get this sour it really needs to
> get into the hands of the authorities, I still think it's worthwhile to
> take some care in implementing this to try and avert these avenues of
> attack. About four hours in, I have the
> open-ils.actor.patron.reset_password.request() call generating entries
> in the actor.usr_password_reset table if given a valid barcode or user
> name, subject to a maximum number of concurrent active requests per user
> (based on OU settings for max concurrent sessions and request
> time-to-live).
>
> Still need to:
>    * cache the "throttle mode" setting so that we don't have to hit the
> database for every request if someone is attempting a denial of service
> via this route
>    * send email with the proper URL to visit - hello, template toolkit
>    * implement the Web interface listening to the special UUID URLs that
> generate a simple password reset form with validation based on the
> home_ou or ancestor regexes if a valid UUID is hit; probably want to
> cache these, too, for a minute or so
>
> Give me another four hours of clear-headed time to focus and I think I
> should have a reasonable implementation together - subject to anyone
> poking significant holes in my current plans for a secure approach, of
> course.
>