[11.x] Use secure randomness in Arr::random() and Arr::shuffle()

[valorin]

This is my long-awaited second attempt at #46105.

The implementations of Arr::random() and Arr::shuffle(), which are also used by Collection, currently use insecure randomness from array_rand() and shuffle(). This replaces those insecure functions with the secure Randomizer::pickArrayKeys() and Randomizer::shuffleArray().

As far as I can tell, these are the last two "random" functions in the framework that aren't using secure randomness. Str::random() was already random, and Str::password() suffered from an unsecure shuffle which this PR fixes.

I know there was an idea to introduce a standalone Random class into Laravel - which is what I've made with https://github.com/valorin/random. Making something like that as part of the Laravel core is still an option, if that is worth doing? This would allow for custom Randomizer Engines to support seeding, etc.
(Note, my package supports older versions of PHP, while a Laravel core version would just need to be 8.2+.)

Additionally, as part of this change, I removed the $seed functionality from shuffle(). If you're relying on seeding randomness, you should be directly implementing seeded randomness functions to ensure nothing changes code wise - rather than relying on third party functions that aren't guaranteed to not change. The old PR failed because a bunch of folks were seeding randomness outside these functions while also expecting specific results from the different functions.

For folks who don't want to implement their own seeded random functions, my Random package offers a good solution to seeded randomness: https://github.com/valorin/random.

If seeds are being used for tests - we could look at replicating the random string factory in use for Str::random() within Arr as a testing helper?

This is targeted at v11, since it contains backwards compatibility breaks.

[Jubeki]

I think it is create to add secure randomness. But it might not be needed in all cases. Therefor the question: Are there performance implications for example with the array shuffle method?

[valorin]

I just ran the following test on my laptop, comparing shuffle() and (new Randomizer)->shuffleArray():

use Illuminate\Support\Benchmark;
use Random\Randomizer;

$list = range(1, 1_000_000);

Benchmark::dd([
    'randomizer' => fn () => (new Randomizer)->shuffleArray($list), 
    'shuffle' => fn () => shuffle($list),
]);

array:2 [
  "randomizer" => "453.126ms"
  "shuffle" => "58.990ms"
]

So it does have an impact, however I'd argue that secure by default is far more important. Folks assume methods like Arr::shuffle() and Arr::random() are secure and can be used for any purpose. If performance becomes an issue, they can implement alternate methods and take the risks associated with those methods.

[Jubeki]

I am on the same page with you. I just wanted people to be aware that security comes with performance tradeoffs and how that might impact their decision for which method to use for the right circumstances.

[valorin]

Ah, good point, thanks! 🙂

[taylorotwell]

Thanks 👍

[TimWolla]

FWIW: This assertion is going to fail in 1 of 720 cases.

[TimWolla]

This is also going to fail in 1 of 720 cases. Combined this gives a failure rate of 1439/518400 for this testcase, which is roughly 1 in 360, which is too high of a false-positive rate for my taste.

[sinnbeck]

Shouldn't this change be in the upgrade guide? The removal of the $seed paramter is sure to break quite a few apps.

[shaedrich]

I know there was an idea to introduce a standalone Random class into Laravel - which is what I've made with https://github.com/valorin/random. Making something like that as part of the Laravel core is still an option, if that is worth doing? This would allow for custom Randomizer Engines to support seeding, etc.

Kinda similar to the idea of \Illuminate\Support\Generator, introduced in #52979 perhaps 🤔