Re: [OPEN-ILS-DEV] Duplicate authtokens

2017-02-08 Thread Mike Rylander 
Ah! I assumed that your bookdrops were using SIP2.  There you go,
nonce to the rescue!

Thanks,

--
Mike Rylander
 | President
 | Equinox Open Library Initiative
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  mi...@equinoxinitiative.org
 | web:  http://equinoxinitiative.org


On Wed, Feb 8, 2017 at 1:40 PM, Bill Ott  wrote:
> 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:  mi...@equinoxinitiative.org
>>   | web:  http://equinoxinitiative.org
>>
>>
>> On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott  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.
>
>

Re: [OPEN-ILS-DEV] Duplicate authtokens

2017-02-08 Thread 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:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org


On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott  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.

Re: [OPEN-ILS-DEV] Duplicate authtokens

2017-02-08 Thread Mike Rylander 
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:  mi...@equinoxinitiative.org
 | web:  http://equinoxinitiative.org


On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott  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.