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

51–60 of 214 posts

Re: Should random() be banned?

#51

Post by makomk »

cpeterso wrote: post #5
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…

Firefox has a secret setting used in test automation called “turn_off_all_security_so_that_viruses_can_take_over_this_computer”. https://searchfox.org/mozilla-central/rev/3ff133d19f87da2ba0...

Yeah, and if I remember correctly one neat technique for exploiting security vulnerabilities in Firefox was to use them in order to set turn_off_all_security_so_that_viruses_can_take_over_this_computer to true, with obvious results.

Re: Should random() be banned?

#52

Post by LolWolf »

tiborsaas wrote: post #20

Meanwhile in graphics programming land: float rand(vec2 co){ return fract(sin(dot(co.xy,vec2(12.9898,78.233))) * 43758.5453); }

Honestly, the one thing that got me into graphics (from physics and math) was just the incredible amount of: "you can literally do anything so long as you make it pretty in the end."

I took that as a life philosophy and it's been pretty great so far.

Re: Should random() be banned?

#53

Post by mreome »

pdpi wrote: post #46
gwbas1c wrote: post #36

Earlier quoted context omitted.

> The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes Cryptographic randomness is typically slower than other forms of randomness. In all of the programming I've done in my career, I've only needed cryptographic randomness a few times. For the rest, a fast pseudorandom number generator seeded by the clock was the correct choice.

Inversely, in my career there's only been a handful of times where cryptographic randomness was too slow. I'd argue it's better to do the safe thing by default and switching to the faster alternative when you have proof you need it. Doing the fast thing by default and fixing security later is how we got Meltdown/Spectre.

It's going to depend on your experience, for me I have often run into the exact opposite extreme... where the non-secure random is to slow for my uses-cases (games, graphics, procedural texture gen, etc) and a much faster but less statistically random generator better suited my needs.

I would argue that the default behavior should favor the novice and non-domain-expert. Should game programmers, graphic programmers, etc, be expected to know that they need to tune the performance of random() or should the domain-experts writing cryptographic algorithms be expected to understand the limitations of random() as it applies to their use-case?

Re: Should random() be banned?

#54

Post by jcranmer »

otabdeveloper4 wrote: post #15
madsbuch wrote: post #4

Is there something I am overlooking here? Randomness is used for many other things than cryptographic usages. Eg. for randomised algorithms you need a fast source of randomness.

No, you are not. Cryptographic random() is an extremely niche use case that you shouldn't be using unless you're writing your own crypto libraries. (Don't do that.)

That's not true.

To answer the question as to when you should use cryptographic random(), ask yourself "What is the worst that could happen if someone guesses the result of random()?"

If the answer is "I don't know," go cryptrographic. You'll save your butt if you didn't know it was important.

If the answer is along the lines of "someone could impersonate a user, or leak information they shouldn't see," for the love of all that is holy, use cryptographic. This is basically every scenario where you are using random to generate an ID of some kind, and while it's only truly critical if that ID is all you need for validation, it does provide another layer of security even if you also require other information to match before giving out elevated access.

If the answer is "it defeats the algorithm I'm trying to do" (think something like ASLR, where you're randomizing the offsets of addresses so that attackers don't know where things are located), well, the reason why you need to use cryptographic should be blindingly obvious.

If the answer is instead "they can reproduce my results," well, you shouldn't use cryptographic in this case. And that's not a lot of cases: Monte Carlo simulations, testing, fuzzing are the obvious poster children for this category, and indeed reproducibility in these cases tends to be a highly valuable feature rather than an anti-feature.

Cryptographic random is almost never harmful to your application, and almost always provides some benefit in reducing guessability of your system. You should err on the side of using cryptographic random(), and only not use it when you are sure that guessability will not harm security in any way and you know that the cryptographic nature actively harms your application.

Re: Should random() be banned?

#55

Post by mreome »

jcranmer wrote: post #54
otabdeveloper4 wrote: post #15

Earlier quoted context omitted.

No, you are not. Cryptographic random() is an extremely niche use case that you shouldn't be using unless you're writing your own crypto libraries. (Don't do that.)

That's not true. To answer the question as to when you should use cryptographic random(), ask yourself "What is the worst that could happen if someone guesses the result of random()?" If the answer is "I don't know," go cryptrographic. You'll save your butt if you didn't know it was important. If the answer is along the lines of "someone could impersonate a user, or leak information they shouldn't see," for the love…

I would argue that if you're asking yourself "What is the worst that could happen if someone guesses the result of random()?" and your answer is "I don't know," then you're doing something you shouldn't be doing.

There are a lot of domains where security is a non-issue and performance is a huge concern (graphics, game logic, many kind of simulations, etc), and the default is the reverse... always just use the installed non-secure random() and if that's too slow consider other options.

Having a flag you can enable to warn about a non-secure random() usage, when it makes sense for your company/usage, sure. But banning it outright makes no sense, and the default behavior you want is very situational.

Re: Should random() be banned?

#56

Post by jcranmer »

mreome wrote: post #55
jcranmer wrote: post #54

Earlier quoted context omitted.

That's not true. To answer the question as to when you should use cryptographic random(), ask yourself "What is the worst that could happen if someone guesses the result of random()?" If the answer is "I don't know," go cryptrographic. You'll save your butt if you didn't know it was important. If the answer is along the lines of "someone could impersonate a user, or leak information they shouldn't see," for the love…

I would argue that if you're asking yourself "What is the worst that could happen if someone guesses the result of random()?" and your answer is "I don't know," then you're doing something you shouldn't be doing. There are a lot of domains where security is a non-issue and performance is a huge concern (graphics, game logic, many kind of simulations, etc), and the default is the reverse... always just use the install…

When it comes to optimization, there's a useful adage: make it work, then make it fast. Secure should really be seen as a necessary component of correct (and that it often isn't is a testament to the failure of our profession).

In that vein, the default random should be cryptographically-secure, with all the logic necessary to actually effect that security (e.g., not reusing seeds after a call to fork). You can also go ahead and provide an insecure random as well, but choosing the insecure random should always be something that the programmer has to go out of their way to do.

Re: Should random() be banned?

#57

Post by btilly »

tedunangst wrote: post #48
njharman wrote: post #39

Earlier quoted context omitted.

Most simulations, games, everything that isn't generating cryptography does not need security in it's random. For most domains secure random is a niche, not universally applicable.

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

The claim that most uses of random() are not in places where cryptographic security is needed is not in conflict with any list of examples where it is needed.

Here are the last several times I saw random() used.

Seeding a neural network for a Coursera course. Not only do you need to call random() a bunch of times, but the ability to set a seed and get deterministic results makes grading of the results massively easier.

Creating simulation data used for integration tests on a piece of software.

Picking a few random numbers that I used in an explanation of an answer.

Of course the plural of anecdote is not data. However in my corner of the world it is very rare to need cryptographically secure anything. And when I do, I know better than to code it myself. But it is common to need a lot of cheap numbers in a hurry.

Re: Should random() be banned?

#58

Post by suzzer99 »

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…

I have required parameter to push our app to production called: YES_I_HAVE_ALREADY_MERGED_THE_LIB_REPOS_AND_WAITED_FOR_THEM_TO_COMPLETE_BEFORE_MERGING_THE_APP_REPOS

Gets the point across and will still work when I'm long gone.

Re: Should random() be banned?

#59

Post by mreome »

jcranmer wrote: post #56
mreome wrote: post #55

Earlier quoted context omitted.

I would argue that if you're asking yourself "What is the worst that could happen if someone guesses the result of random()?" and your answer is "I don't know," then you're doing something you shouldn't be doing. There are a lot of domains where security is a non-issue and performance is a huge concern (graphics, game logic, many kind of simulations, etc), and the default is the reverse... always just use the install…

When it comes to optimization, there's a useful adage: make it work, then make it fast. Secure should really be seen as a necessary component of correct (and that it often isn't is a testament to the failure of our profession). In that vein, the default random should be cryptographically-secure, with all the logic necessary to actually effect that security (e.g., not reusing seeds after a call to fork). You can also…

Secure should really be seen as a necessary component of correct security. I don’t see random() as part of security, and the problem is that people use it as such (that’s the failure of our profession as I see it). You wouldn’t want the default string equality operator to be constant time to prevent a possible timing attack, and in the same way I don’t think random() should be cryptographically secure by default. If you need secure random values, you are (should be) a domain-expert and should be selecting an appropriate cryptographically secure random generator from a security library, in the same way you would with a constant-time equality function.

I guess it's a matter of perspective over who random() is for. I see random() as for the programmers who don't know what kind of randomness they need, and don't need to know that because they just need something 'random' not something secure. I expect the domain-experts to know that it's not what they need. In my mind it's not that random() is not secure, it's that using it for something it's not intended for is insecure.

Re: Should random() be banned?

#60

Post by Sohcahtoa82 »

tedunangst wrote: post #48
njharman wrote: post #39

Earlier quoted context omitted.

Most simulations, games, everything that isn't generating cryptography does not need security in it's random. For most domains secure random is a niche, not universally applicable.

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?"

Post reply on HN