Re: random token re-used in subsequent requests

> On May 16, 2016, at 1:26 PM, André Warnier <[email protected]> wrote:
> 
> I may be wrong, but at least intuitively, this does not seem to be an optimal way to obtain a 32-char long random key.
> 

It’s about 30% slower to run 

join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32;

versus 

$r= join "", map @a[rand(10+26*2)], 1..32;

With "@a =map +(0..9,"a".."z","A".."Z”);” declared only once, based on some Q&D testing.

 (I had to boost the iterations to 2.5e^6 times for each mode to reach 47 v 36 seconds on my desktop here, so in practice running once per page change on the server it’s not going to be noticeable either way)

I agree that 32 bytes are probably excessive, but on the other hand it also makes it more unlikely even a poor random number generator would generate two identical strings in such close proximity, let alone do it regularly.


>> If it’s properly seeded in the original code, it should either work or not work on all five servers. Not working on one out of the five makes me think maybe there’s some sort of weird caching issue.
>> 
> 
> I agree, that the seed is the main issue.
> The code should insure that for each server process (+ perl interpreter), srand() is called once, whence that process starts (or the first time the webapp is run), and with a different seed for each process.

This is automatic when rand() is called without srand() being invoked. <http://perldoc.perl.org/functions/srand.html> so it’s already being done when the code is run on each server + new interpreter. The only way to get a repeatable random sequence is to explicitly call srand() with a  parameter. 

The perldoc page on rand() explicitly says that it’s not cryptographically safe, but there’s a very large gap between "cryptographically safe” and "quickly and readily repeats randomly generated 32-byte strings”. It’s good enough for this purpose.

I  really do not think that the source of the random token is the issue here, but the server (or something else, a load balancer, something like that?) caching the request parameters for some reason. 

Possibly the server is not recognizing it as a new request, and thus not generating the new token.

I don’t think it would be likely for Vincent to ever see this once, let alone have it rise to the issue of a problem if it were strictly about non-randomness of the rand() function.

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs