[OPEN-ILS-DEV] Duplicate authtokens

[Bill Ott]

Unfortunately, at the time I caught this in the logs, we were only 
logging warn, so I don't see the init call.  The method we were using to 
call init was not using nonce.

I've located a nice example in SIP.pm and will make a code change to use 
it in our init call going forward!



On 02/08/2017 01:15 PM, Mike Rylander wrote:
> Bill,
>
> Can you find the log entries for the offending sessions (should all be
> around 6am, obv) for calls to open-ils.auth.authenticate.init?  The
> first parameter is the username and the second is the nonce
> (http://stackoverflow.com/questions/5050932/nonce-usage-in-authentication)
> used to disambiguate session requests coming in at the same time.  The
> nonce is based on the return value of rand($$) in the client (a random
> number between 0 and the client pid minus 1), and if they're the same
> then the same auth token could be generated.  They should not be the
> same, of course, but if they are ... we may need to upgrade our PRNG
> to something stronger from CPAN, like
> http://search.cpan.org/~frew/Math-Random-Secure-0.08/lib/Math/Random/Secure.pm
>
> Thanks,
>
> --
> Mike Rylander
>   | President
>   | Equinox Open Library Initiative
>   | phone:  1-877-OPEN-ILS (673-6457)
>   | email:  miker at equinoxinitiative.org
>   | web:  http://equinoxinitiative.org
>
>
> On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott <bott at grpl.org> wrote:
>> I'm not sure this if this is a bug, as I haven't totally wrapped my mind
>> around it, but we've had some bizarre behavior that I wanted to put on the
>> radar.
>>
>> Ever since we upgraded to 2.11 in Dec., we've had occasional situations
>> where our automated book drops would start reporting the wrong OU on
>> checkin.  The WS name would be correct, but not the OU.  A restart of the
>> book drop service would correct it.  I hadn't reported it because I thought
>> it may have something to do with our custom services.
>>
>> Today I found the smoking gun in the logs.  Drops restart every morning at
>> 06:00.  They are using the same user, but different WS values.  The logs
>> showed 4 drops all with the same authtoken. When retrieving the ws_ou by
>> authtoken, you'd get the OU based on the first WS value.
>>
>> I'm not sure if this is something with the new auth code, and we can't
>> reproduce it manually, but it seems that there's something about requesting
>> multiple logins using the same user at the same moment that causes
>> authtokens to be reused, even though the WS is different.
>>
>> We've now created new distinct users for each drop and I suspect that will
>> prevent us from seeing this, but it seemed worth mentioning.