perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce Johnson" <john...@Pharmacy.Arizona.EDU>
Subject Re: random token re-used in subsequent requests
Date Mon, 16 May 2016 22:45:14 GMT

> On May 16, 2016, at 1:26 PM, André Warnier <aw@ice-sa.com> 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

Mime
View raw message