In Depth: Securing Randomness Without Breaking Things
[InDepth#14] Cryptographically secure randomness is important, but so is backwards compatibility...
Greetings friends! As promised, this week we’re looking at a Pull Request I made to Laravel a month ago, introducing proper cryptographically secure randomness to Laravel’s randomness functions. Sounds simple right? Nope! It caused a bunch of backwards compatibility issues, spawned an interesting debate, and was ultimately rolled back1. Let’s first look at my fixes, why I felt they were important, then why we rolled them back, and what the plan is going forward.
Please consider becoming a paid subscriber to support Laravel Security in Depth.
You’ll receive weekly security tips and monthly In Depth articles (like this one!), covering every aspect of building secure applications in Laravel.
👉 Security Audits: Want me to hack your app and help you improve your security? 🕵️
Looking to learn more?
⏩ Security Tip #25: Login Logging
▶️ In Depth #9: Signed URLs
Securing Randomness Without Breaking Things
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?
Keep reading with a 7-day free trial
Subscribe to Securing Laravel to keep reading this post and get 7 days of free access to the full post archives.