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

181–190 of 214 posts

Re: Should random() be banned?

#181

Post by ThePadawan »

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.

I was trying to generate random string identifiers to make some element ids unique and took the most popular library, which was accidentally crypto levels of secure:

https://blog.prat.ch/2020/11/10/randomstring-bundle-size

Re: Should random() be banned?

#182

Post by nicoburns »

andoriyu wrote: post #95
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.

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

The point of `dangerouslySetInnerHTML` is also to highlight an area which requires more human attention. It's perfectly safe if you have otherwise handled escaping or validation of the content. It's just that you want to pay careful attention to that code to ensure that you're doing it correctly, whereas in normal React code you don't have to think about escaping at all because the runtime handles it for you.

Likewise `unsafe` marks areas where you need to be really careful that you upholding the safety invariants yourself, whereas in normal Rust code you don't need to think about that at all.

Re: Should random() be banned?

#183

Post by account42 »

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?

> Fix Rate is the percentage of merge-blocking findings that are fixed (i.e., not muted*) in CI. We believe this is a proxy for engineering value. As we run our own developer-focused security programs, we’re obsessing over how to increase the Fix Rate for the rules on our projects.

> Observing a bad 0% Fix Rate for random() (with only 7 data points from our projects), we decided to silence the rule for r2c developers

Re: Should random() be banned?

#184

Post by fanf2 »

tgsovlerkhgsel wrote: post #133
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 -…

I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications. The main arguments I've seen are speed and determinism. However, a cryptographically secure, deterministic PRNG can be built from hash or block cipher primitives that have hardware acceleration, making them quite fast. Seed (and potentially periodically re-seed) it from a strong source of randomness, a…

The most common case for me is when fuzzing, when I want reproducible random numbers, so it must be possible to initialize the RNG from a known fixed seed so that I can re-run and debug a failure.

Re: Should random() be banned?

#185

Post by fanf2 »

Khaine wrote: post #136
patrec wrote: post #94

Earlier quoted context omitted.

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…

Doesn't FreeBSD use Mersenne Twister as its CSRNG?

No, FreeBSD uses Fortuna https://en.wikipedia.org/wiki/Fortuna_(PRNG)

Mersenne Twister is not secure, and it isn’t a very good RNG even for insecure uses.

Re: Should random() be banned?

#186

Post by fanf2 »

esrauch wrote: post #74
josephg wrote: post #67

Earlier quoted context omitted.

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

This is extremely bad advice. It is shamefully unethical to encourage people to harm their security in this way.

Re: Should random() be banned?

#187

Post by Quillbert182 »

IcePic wrote: post #174
Quillbert182 wrote: post #85

Semi-unrelated question: How secure are the hardware random number generators on say, a raspberry pi. Would these sort of things be cryptographically secure?

I think those built-in RNGs should be treated like RDRAND on x86, you may mix them into the pool along with all the other sources of entropy your platform supplies, and then generate cryptographic streams seeded out of the pool. Using them alone might turn out to be a bad idea in the long run.

Would /dev/random be the combined entropy?

Re: Should random() be banned?

#188

Post by kortex »

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

This just kind of proves GP's point. Random APIs usually tell you what the RNG is, but not the why/how. Most people don't care if it's /dev/(u)random, Mersenne twister, PCG, LFSR, LCG, RDRAND, etc. They care about roughly 4 attributes:

- Is it good for crypto

- Is it fast

- Is it reproducible

- Is it portable

But fundamentally, it's about the use case and interface:

- I need secure random (strong, slow, secure)

- I need Monte Carlo (good enough, fast, reproducible)

- I need chaotic behavior for my game/stress test/back off protocol (usually can be barely random, fast, reproducible)

I think calling the last case InsecureRandom or RandomEnough is reasonable to convey "don't use me for secure purposes".

Re: Should random() be banned?

#190

Post by h_anna_h »

lmm wrote: post #160
h_anna_h wrote: post #106

Earlier quoted context omitted.

> If you want predictable "random" numbers, you should have to jump through additional hoops Why? > By default random numbers should be cryptographically secure. Why not both?

> Why? Because you're doing something that often causes major security bugs. > Why not both? It's not possible for random numbers to be both predictable and secure at the same time.

In addition to what bscphil said

> Because you're doing something that often causes major security bugs.

Okay, sure, but I might be running a simulation or something, why should I be punished because some idiot decided to srand(time(0))?

Post reply on HN