That's not good! Taking a look.

EDIT: I believe it's because the CSPRNG state ( https://metacpan.org/pod/Bytes::Random::Secure::Tiny ) was created before the process forks, so they shared the initial state and generated the same token. I've reduced it to 1 worker pending an actual fix.

Sorry about that, and thanks for pointing it out.

There was a recent discussion about (not) sharing CSPRNG state with fork-ed processes: https://news.ycombinator.com/item?id=15759855

Given this kind of disaster potential, wouldn't it be a rather attractive option to use /dev/urandom?

Bytes::Random::Secure::Tiny seeds itself from /dev/urandom, I just need to make sure to initialise it on first use, instead of when my program first starts (which I've now done).

In general I suspect if anything you'd be more likely to mess it up by reading bytes from /dev/urandom manually than by using a library.

How exactly can one mess up reading bytes from `/dev/urandom`? Serious question.

Open the file. Read from it. If no failures on open or read, you have random bytes. In essence, there is already a library for this: `open` and `read`, which seems to be the same API surface area as this library.

Here's all the ways this can possibly go wrong:

https://insanecoding.blogspot.com/2014/05/a-good-idea-with-b...

Most of these are ridiculous.

First, the author mentions that a `read` from urandom can be interrupted. I am unaware of any system where this is actually possible. And even if it were, the author's original code (and my description of an implementation) already works! The `read` call will return an error, and that error is handled. His "improved" code is simply an optimization around retrying from this device, but it's not an improvement in safety.

His second argument is that /dev/urandom might not have enough randomness in it. This is, quite simply, not a concern for anyone not writing code for specific embedded devices or for extremely early in the kernel boot process. Anyone who is writing code for these environments is almost certainly already aware of these limitations. And even then, using a library like the one the GP is using doesn't actually help, since it's virtually guaranteed to just be reading bytes from `/dev/urandom` for its seed in the first place.

The rest go into situations that — quite frankly — border on ludicrous. If someone has replaced your `/dev/random` with `/dev/zero`, you have already lost and there is nothing you can or should reasonably do besides nuke the machine from orbit.

I though the main issue of reading bytes from /dev/urandom was performance (ignoring the issue of ensuring /dev/urandom has been initialized since boot.)

So instead, we use them to seed CPRNGs, and use them for speed.

This implies that you should probably invalidate all URLs created before you applied that mitigation, right? Or do you have some way (logs?) of knowing which ones were compromised?

+1 for using Perl

Care to share your stack?

Hey, sorry for the late reply. Not sure if you'll read this...

It's mostly http://mojolicious.org/

SQLite for the database (for now; that'll change if it gets too big), and nginx as a reverse proxy in front of Mojolicious. CentOS 7.

Cool thank you for response.

Well, did you go to the URL so that that user will know they used an insecure service?

They forgot to dogfood their own product