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

91–100 of 214 posts

Re: Should random() be banned?

#91

Post by cryptica »

I hate how bloated software development has become nowadays and I hate all these tools which keep raising warnings about vulnerabilities which are not relevant to the use case.

It's unbelievable that we live in a society where we're obsessed with achieving 100% test coverage of all our small petty software systems but our monetary system itself (the mother of all systems) is not even integration tested... First time anyone ever heard the word 'test' when discussing the financial system was 'stress test of the banking sector' after 2008 crisis and these tests are so superficial, it's a joke! What's worse about the monetary system is that known vulnerabilities don't even get patched after decades of active exploits! With all its unnecessary bureaucracy, the software industry is a joke. What is the point of all this rigorous software testing infrastructure when the entire environment within which the software exists is unsound and untested? Managers don't trust their developers... But it's the managers who don't deserve to be trusted.

Re: Should random() be banned?

#92

Post by yellowapple »

tedunangst wrote: post #75
Sohcahtoa82 wrote: post #60

Earlier quoted context omitted.

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.

I personally parsed the claim as "most (simulations, games, everything)" rather than "(most simulations), games, everything", but I can see how that can go either way.

Re: Should random() be banned?

#93

Post by setr »

nicoburns wrote: post #41
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…

React's dangerouslySetInnerHTML is indeed a good way of handling this kind of thing. Rust's `unsafe` is another example of the same approach.

I don't think rust's unsafe says anything about cryptographic security, beyond pointer-safety implications.

Re: Should random() be banned?

#94

Post by patrec »

SomeCallMeTim wrote: post #66
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.

Actually, in my experience using the default random implementation in games: * It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise. So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2] It's not cryptographic, but it's far better for games. If you're not going to hav…

Mersenne Twister is the MD5 of random number generators: it's neither secure nor fast (and unlikely md5 not space-efficient, or simple to implement either). You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation.

So given that Mersenne Twister sucks in pretty much every possible way other than having a catchy name, likely the sole source of its continued popularity, its probably not a good choice for replacing some "default" random number generator with something better.

Re: Should random() be banned?

#95

Post by andoriyu »

nicoburns wrote: post #41
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…

React's dangerouslySetInnerHTML is indeed a good way of handling this kind of thing. Rust's `unsafe` is another example of the same approach.

uhm no.

Rust's "unsafe" is a pretty bad name and completely different reasoning behind using it. It doesn't mark something as "dangerously unsafe, don't use", to a consumer it indicates "exercise caution" and to a compiler it just allows 5 things:

    Dereference a raw pointer
    Call an unsafe function or method
    Access or modify a mutable static variable
    Implement an unsafe trait
    Access fields of unions
The point of "unsafe" in rust is to highlight which area requires more human attention... not to discourage its usage.

`dangerouslySetInnerHTML` is literally dangerous and allows XSS if used with outside input.

It also is faster than the other variant. The same is true for `random()`. Both can be used when you know what are you doing to gain some performance.

Meanwhile, `unsafe` rust by itself is not different from safe rust in terms of speed. You have no choice, but to use it places it supposed to be used.

Re: Should random() be banned?

#96

Post by extropy »

1MoreThing wrote: post #71
Macha wrote: post #61

Earlier quoted context omitted.

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.

The problem is that true random is quite expensive without dedicated hardware and you can still easily bias true random if you are not careful.

IMO there is no use of true random unless you really know what you are doing.

Also there is true random - pure entropy bits and there is cryptographically secure pseudorandom, seeded with true random bits.

Re: Should random() be banned?

#98

Post by Macha »

CivBase wrote: post #65

Most static code analysis tools I've used allow you to write exceptions for rules into your code using comments that follow a particular signature. Isn't it sufficient to just ban the use of random() and require devs to use one of those comments to effectively "sign off" on it if they encounter a good use case?

There's two trains of thoughts here:

1. You can disable lint warnings, so it's no big deal if some rules have false positives

2. Disabling lint warnings should be a code smell, so if there's some rule that's getting people used to disabling lint warnings, it is a problem.

I'm on camp 2 on this rule.

Re: Should random() be banned?

#99

Post by city41 »

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 -…

Interestingly a major aspect of video game speed running is figuring out how the game generates random numbers then exploiting the knowledge. For example speedrunners avoid all random battles in an rpg with this tactic. I'm not arguing games need true random for the record.

Re: Should random() be banned?

#100

Post by nicoburns »

setr wrote: post #93
nicoburns wrote: post #41

Earlier quoted context omitted.

React's dangerouslySetInnerHTML is indeed a good way of handling this kind of thing. Rust's `unsafe` is another example of the same approach.

I don't think rust's unsafe says anything about cryptographic security, beyond pointer-safety implications.

Neither does React's dangerouslySetInnerHTML. What both of these do is mark a potentially dangerous operation with an in-your-face warning message that you have to go out of your way to ignore. Which in practice is very useful, as often the biggest problem with security issues is not know what you don't know. It's impractical to review the entire codebase on a regular basis, and it can be hard to know which bits to focus on.
Post reply on HN