40 ms·

> this type of incident used to pop up on HN every month or so, and yet in the past few years they've become incredibly rare. And do you know why that is? It i

> this type of incident used to pop up on HN every month or so, and yet in the past few years they've become incredibly rare. And do you know why that is? It is not because developers got better. It's almost entirely due to the fact that development frameworks (particularly JS in browsers) have made a multi-year and systematic effort to reduce the availability of insecure default PRGs to bad developers. The result is that an entire bug class has gone from a common, monthly occurrence, to a relative rarity. That's a fair take and worth considering. I suspect this whole dilemma speaks to a widening divide between those who see security as the top and inviolate priority in modern software and those still seeing software as something with much more varied and heterogenous concerns. And that gap gets most contentious when it comes to what things like what should be considered default, what capabilities should be available altogether, how convenient those features should be made, what emphasis should be made in education/training/mentorship, etc. Undoubtedly, (often sloppy) network-delivered and network-attached software has come to dominate the industry and with it the consequences of security-practice lapses have become be more severe than they once had been. But at the same time, we can watch as things like correctness, stability, resource-efficiency, performance-efficiency, maintenance/repair-ability, etc tumble away and turn much of the same software into byzantine garbage that barely runs on X-core YYY-ghz hardware with ZZ-gigabytes of RAM and faults have the time when it does. So I think there's a real tension, but I get where you're coming from. It may in fact be true that making a seeded PRNG less easily available would be a wise favor to the security-first-and-always people. :D

matthewdgreen 2y ago
Just to beat the horse to death, I want to be clear that what I'm asking for isn't much: 1. The default random() call/library should always produce exactly what it says -- real, secure, unpredictable (pseudo)random numbers. 2. For statistical and non-security applications it's perfectly fine to have a generator of the form random.insecureAndFast(). Or call it whatever you want, the important thing is that the developer make a tiny amount of conscious effort in the process of using it. 3. If you require reproducible and insecure generator, just use approach (2) above and add a seeding function. (Honestly I don't like anything that uses global state, but I don't care as long as it's labeled insecure.) 4. If you require reproducible and secure random numbers, then you have a slightly challenging problem on your hands that is way beyond the scope of this discussion. For people who don't require secure randomness, the total "cost" of my proposal is something like an extra dozen characters added to your code in a few places -- and if that's too much work for you, then you probably aren't writing reproducible tests or spending a lot of time optimizing for speed. On the flipside, you might save someone a few million dollars when their crappy Bitcoin library uses a dependency that relies on random().
- liontwist 2y ago
  I think this is a reasonable solution. I also hope we can standardize a random function which takes an integer range of maximum.

matthewdgreen 2y ago

Just to beat the horse to death, I want to be clear that what I'm asking for isn't much: 1. The default random() call/library should always produce exactly what it says -- real, secure, unpredictable (pseudo)random numbers. 2. For statistical and non-security applications it's perfectly fine to have a generator of the form random.insecureAndFast(). Or call it whatever you want, the important thing is that the developer make a tiny amount of conscious effort in the process of using it. 3. If you require reproducible and insecure generator, just use approach (2) above and add a seeding function. (Honestly I don't like anything that uses global state, but I don't care as long as it's labeled insecure.) 4. If you require reproducible and secure random numbers, then you have a slightly challenging problem on your hands that is way beyond the scope of this discussion. For people who don't require secure randomness, the total "cost" of my proposal is something like an extra dozen characters added to your code in a few places -- and if that's too much work for you, then you probably aren't writing reproducible tests or spending a lot of time optimizing for speed. On the flipside, you might save someone a few million dollars when their crappy Bitcoin library uses a dependency that relies on random().

liontwist 2y ago
I think this is a reasonable solution. I also hope we can standardize a random function which takes an integer range of maximum.