Re: random token re-used in subsequent requests

On 17 May 2016 at 15:10, André Warnier <[email protected]> wrote:
> On 17.05.2016 14:11, Vincent Veyron wrote:
>>
>> On Tue, 17 May 2016 10:16:43 +0200
>> André Warnier <[email protected]> wrote:
>>>
>>>
>>> I don't see above any signifiant difference in configuration between the
>>> servers, apart
>>> from the fact that the "faulty" server runs a 64-bit version of perl.
>>
>>
>> Sorry : slightly digressive rant about the fact that every time I compare
>> my configs, I find some subtle differences. Should be getting into config
>> management tools, but that takes time too.
>>
>>>
>>> Now I also found this :
>>>     http://rabexc.org/posts/randomizing-should-be-easy-right-oh
>>>
>>> I am not sure that I really understand this all the way down, but would
>>> this not be a
>>> suspect in a case where the behaviour seems different between one 64-bit
>>> machine, and a
>>> bunch of 32-bit ones ?
>>
>>
>> Nope; same results on both types when running the script
>>
>>>
>>> This being said, it still looks to me as if the current code is flawed on
>>> *all* machines,
>>> and *will* repeat keys quite often. It just depends again on the exact
>>> sequence of
>>> requests hitting a specific Apache, and the other parameters I mentioned
>>> before.
>>> I still believe that the fact that it does not *seem* to happen, is just
>>> due to the
>>> inherent randomness of these other factors on the production machines.
>>>
>>
>> Well, I already posted a test with ab and 12 000 requests, so not sure
>> about the 'quite often' part?
>>
>> This is on the faulty one :
>>
>> xxxx@arsene:~$ perl -le '%h=();for (1..10_000_000) {my $session_id = join
>> "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)],
>> 1..32;$h{$session_id}=1};$v=keys %h; print $v'
>> 10000000
>>
>>
[SNIP]
> And this "disorder" will tend to be larger, the more loaded is that server.
> So over any given period of time, each child will tend to be at a different
> stage in his rand() calls. And the risk of having the same key being
> returned to 2 clients at about the same time, is relatively low.
> But if the keys are stored somewhere in a persistent way, you are increasing
> the risk greatly, because key #13 generated by a new child today, may
> conflict with the key #13 generated by another child yesterday.
>
> (*) or start an additional child
>

a very simple solution to this problem is to put the time in the string eg:

my $token= pack "LC*", time, map int rand 256, 1..$number_of_bytes_in_token;

then just hex encode or base64 encode the string.

Doing it this way also probably massively faster (done right) than the
approaches i have seen mentioned in this thread. pack is *fast*.

Note the chance that two drand48 states are the same at the same time,
is really really low if sranded properly. Essentially zero.

Yves

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"