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