Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should random() be banned?

r2c.dev

Post reply on HN
Print view View original

71–80 of 214 posts

Re: Should random() be banned?

#71

Post by 1MoreThing »

Macha wrote: post #61
ThePadawan wrote: post #3

I'm not big on bans. What I am big on is forcing developers to make deliberate choices. That's why I like React's policy of naming functionality "dangerouslySetInnerHTML" or "__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED". If you add usages for these in a PR I'm reviewing without justification, it's not getting merged. So why not make cryptographically unsafe random unsafeRandom() or shittyRandom() or iCopyPastedThisF…

This assumes writing crypto code is the most common use case for random numbers. How often do you write crypto code? vs How often do people use random numbers + threshold for A/B tests? How often do game developers use random numbers for gameplay variety? How often is random used for animation variety? Do these use cases need the overhead of a cryptography RNG? A former employer had the same issue as in the article -…

The creation of a trueRandom function certainly seems to solve this problem more than taking away a useful tool for cases where pseudo-random is good enough.

Re: Should random() be banned?

#72

Post by nixpulvis »

throw0101a wrote: post #68
admax88q wrote: post #62

Just make Math.random() cryptographically secure, now all your apps are fixed, and no existing code broken. I can't imagine anything relying on Math.random() being "less" random than a CSRNG. Why must CSRNGs always have alternative obtuse APIs. We're still stuck on C style srand() + rand(). Cryptography is so ubiquitous now that failure to provide cryptographically secure random numbers should be viewed as a hardware…

Some folks purposely want random-ish results. When OpenBSD was changing the behaviour of its legacy POSIX random functions it was observed: This API is used in two patterns: 1. Under the assumption it provides good random numbers. This is the primary usage case by most developers. This is their expectation. 2. A 'seed' can be re-provided at a later time, allowing replay of a previous "random sequence", oh wait, I mea…

Unless I'm wrong, the only valid reason to not use a better random number generator is for performance / simplicity, which then demands benchmarks and evaluation.

Re: Should random() be banned?

#73

Post by FalconSensei »

Macha wrote: post #61
ThePadawan wrote: post #3

I'm not big on bans. What I am big on is forcing developers to make deliberate choices. That's why I like React's policy of naming functionality "dangerouslySetInnerHTML" or "__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED". If you add usages for these in a PR I'm reviewing without justification, it's not getting merged. So why not make cryptographically unsafe random unsafeRandom() or shittyRandom() or iCopyPastedThisF…

This assumes writing crypto code is the most common use case for random numbers. How often do you write crypto code? vs How often do people use random numbers + threshold for A/B tests? How often do game developers use random numbers for gameplay variety? How often is random used for animation variety? Do these use cases need the overhead of a cryptography RNG? A former employer had the same issue as in the article -…

Also: if someone is working on crypto and doesn't know that random() isn't true random, should they be working on that?

Re: Should random() be banned?

#74

Post by esrauch »

josephg wrote: post #67
epanchin wrote: post #43

Earlier quoted context omitted.

And one would hope secure devs know which random to use, whereas gaming devs have no reason to know.

Look up “password generator” or similar terms on npm and take a look at how the packages you find generate random numbers. I did this ~5 years ago and it took until the second page of results before I found any packages that used a crypto-secure rng.

Even that seems unlikely to be problematic for anything short of literally constant seeds AND a generator becoming extremely popular.

The vast majority of people reuse low-entropy passwords, figuring out what password generator someone used would be a much higher bar than figuring out passwords, and just knowing the insecure generator wouldnt reduce the entropy by that much.

Actually, a password generator on GitHub that generates the password that is literally just seconds-since-1970 would still be a good generator for almost all use cases.

Re: Should random() be banned?

#75

Post by tedunangst »

Sohcahtoa82 wrote: post #60
tedunangst wrote: post #48

Earlier quoted context omitted.

So a simple linear generator is fine for an online poker game?

Well of course an online poker game should be using a CSPRNG. The parent comment said " Most simulations, games ...". Most. Not all. I think it's pretty obvious that Poker would not be included a statement of "Most". The real litmus test is the question of "What happens if a malicious actor is able to predict the random numbers?"

The claim was that everything that isn't generating cryptography does not need security.

Re: Should random() be banned?

#76

Post by admax88q »

throw0101a wrote: post #68
admax88q wrote: post #62

Just make Math.random() cryptographically secure, now all your apps are fixed, and no existing code broken. I can't imagine anything relying on Math.random() being "less" random than a CSRNG. Why must CSRNGs always have alternative obtuse APIs. We're still stuck on C style srand() + rand(). Cryptography is so ubiquitous now that failure to provide cryptographically secure random numbers should be viewed as a hardware…

Some folks purposely want random-ish results. When OpenBSD was changing the behaviour of its legacy POSIX random functions it was observed: This API is used in two patterns: 1. Under the assumption it provides good random numbers. This is the primary usage case by most developers. This is their expectation. 2. A 'seed' can be re-provided at a later time, allowing replay of a previous "random sequence", oh wait, I mea…

This is exactly what I mean about being stuck in the C mindset. You're looking at the problem though the lens of what this giant pile of ancient C software does.

Why should newer languages take the same approach to APIs that these old code bases did? It's not like we're porting all those programs to JS. Those C APIs were written long before hardware could provide fast good randomness, heck even before cryptography was standard practice instead of a special use case.

Not to mention in JS you can't even seed the random number generator. If you want predictable "random" numbers, you should have to jump through additional hoops. By default random numbers should be cryptographically secure.

EDIT: It's also worth mentioning that from your reported dataset, 41 of 8800 programs analyzed used srand to get a repeatable set of "random" numbers. That's 0.47%. I'm happy to break less than half a percent of software if it helps prevent the far more ubiquitous failures of software using insecure random numbers.

Re: Should random() be banned?

#77

Post by throw0101a »

admax88q wrote: post #76
throw0101a wrote: post #68

Earlier quoted context omitted.

Some folks purposely want random-ish results. When OpenBSD was changing the behaviour of its legacy POSIX random functions it was observed: This API is used in two patterns: 1. Under the assumption it provides good random numbers. This is the primary usage case by most developers. This is their expectation. 2. A 'seed' can be re-provided at a later time, allowing replay of a previous "random sequence", oh wait, I mea…

This is exactly what I mean about being stuck in the C mindset. You're looking at the problem though the lens of what this giant pile of ancient C software does. Why should newer languages take the same approach to APIs that these old code bases did? It's not like we're porting all those programs to JS. Those C APIs were written long before hardware could provide fast good randomness, heck even before cryptography wa…

I'm looking at the problem through the lens of changing the behaviour of an existing API.

If you want to create 'secure' APIs that 'do the right' thing, I'm not against it. But leave the old stuff around, or mark it deprecated, throwing warnings and errors on compilation even, for possible future removal—don't change it.

Re: Should random() be banned?

#78

Post by not2b »

There are many uses of random() that do not require cryptographic security: simulation, simulated annealing, sound synthesis, digital signal processing and the like. It would be a nuisance if developers of those kinds of software have to fight warnings because developers of completely different applications can't get it right.

Re: Should random() be banned?

#79

Post by not2b »

not2b wrote: post #78

There are many uses of random() that do not require cryptographic security: simulation, simulated annealing, sound synthesis, digital signal processing and the like. It would be a nuisance if developers of those kinds of software have to fight warnings because developers of completely different applications can't get it right.

Further, such users usually want to be able to repeat a test case: start from the same seed, get the same sequence. They don't want true randomness, they want a repeatable sequence with good statistical properties.

Re: Should random() be banned?

#80

Post by antonyh »

Seeded random is a glorious thing in the right circumstances. As an example, I've used it for 'random' testing sequences (jumbling up a list of inputs) but in a way I can later re-run EXACTLY the same test.

It's also useful for other data generation tasks where the output can basically be saved as a seed, making it lightweight and easy to store - it could be written it on a scrap of paper in seconds.

Maybe it's a bad name though - it should be called seededRandom() or semiRandom() or deterministicRandom(). Or perhaps it should be true random is no seed is set. Hard to know. Maybe the true random only needs to be the seed to a deterministic random and reset on a frequent basis in some cases.

Then there's the category of casual random that doesn't matter, like random colours just for the sake of it. It doesn't need to be a secure safe random.

And... assuming that any random function is truly random is a mistake anyway. Basing on hardware, and it may fail. Base it on software and where's the source of entropy. Add to that the possibility of bugs/defects in the implementation, and it's possible that it might not be as random as it needs to be. It's better to assume ALL RNGs are PRNGs, with the caveat that some are decidedly better than others.

So no I wouldn't support a ban on it, nor would I support removing it from any language/runtime where it might be useful.

Post reply on HN