In Depth: Securing Randomness Without Breaking Things
[InDepth#14] Cryptographically secure randomness is important, but so is backwards compatibility...
Back in Tip #19, I wrote about Cryptographically Secure Randomness2, and advised that Laravel’s `Arr::random()`
and `Arr::shuffle()`
methods are not cryptographically secure, and therefore should be considered unsafe to use for any secure applications or purposes that require true randomness. (I’ll explain why they aren’t secure shortly.)
While these methods are fine for things like displaying a list of items in a random order every time a page loads, they are also commonly used for things like picking competition winners and generating passwords and tokens. In both of these cases, predictability is a problem that can introduce bias or allow an attacker to guess values and bypass security controls.
A great example, which I am unable to find a link for3, is referenced on Security StackExchange: “In practice, cases where it will actually make a real difference are extremely rare, but there have been cases where it has been abused. The best (and only) example I know of is at a casino slot machine in Montreal where this guy spent weeks trying to find patterns and eventually did because of the seed.”. The Lumiere Place Casino in St. Louis noted similar attacks on their slot machines. While these examples aren’t specific Laravel or even PHP based, both occurred due to the use of insecure randomness.
Insecure Implementations
So the first question is: Why are Laravel’s methods insecure?