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

201–210 of 214 posts

Re: Should random() be banned?

#201

Post by rightbyte »

Macha wrote: post #98
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.

> Disabling lint warnings should be a code smell

I believe lint warnings are for pointing out unusual constructs that might be a mistake not to be a code police.

Re: Should random() be banned?

#202

Post by CivBase »

account42 wrote: post #183
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

I wouldn't necessarily consider a fix rate of 0% to be bad. If you're doing something that looks bad, you should probably leave a comment that silences the static analysis error and justifies why you're doing it. If that justification is missing, the static analysis tool should flag it IMO.

If using random() in a crypto project is a bad code smell, then I'd say every use of it should come with a brief justification.

Re: Should random() be banned?

#203

Post by cogman10 »

bigiain wrote: post #150
cogman10 wrote: post #26

Earlier quoted context omitted.

That's be my preference. random() should be the most universally applicable random which includes making it as secure as possible. Non-universally applicable randoms should be named accordingly.

I completely disagree here. I’d bet a lot of money that the number of times random() is used in a non cryptographic context is many orders of magnitude higher than the use of random numbers in crypto code. That make non crypto use “the most universally applicable” case. I would also agree that “non universally applicable random” such as those used in crypto code should be named accordingly. Which they are. Secure_ran…

Why put security second?

The thing is, if you need random numbers fast, then profiling will tell you "Opps, used random() when I should have used fast_random()". That's an easy change to make that'd show up in profiling if performance were an issue.

If random() never comes up in profiling, why care that you are getting the secure version?

The danger of missing "secure_random()" is that it creates a security vulnerability (Potentially leading to loss of money, information, etc). The danger of going the "fast_random()" route is that your application will run slower potentially leading to a dev needing to spend time to swap in "fast_random()" for "random()". That, to me, doesn't seem like a major problem or risk.

Programmers are notoriously bad at predicting when something will end up being a performance issue. So why preoptimize because we assume most people want/need speed?

Re: Should random() be banned?

#204

Post by h_anna_h »

admax88q wrote: post #199
h_anna_h wrote: post #190

Earlier quoted context omitted.

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

Because your in the minority. Why should rand() be reserved for your use case and people with other use cases need to use a more obtuse SecureRandom() API? Defaults should be secure. The simple case should be secure.

> Why should rand() be reserved for your use case

Because rand has a specific and well defined meaning. In addition I see no evidence that this use-case is any less popular. Anyway, this subthread is about having to go through extra hoops to have deterministic random numbers, your post is irrelevant to that. I do not think that anyone would be against defining random() to return a secure random number in your language.

> Defaults should be secure

Are you supporting that new computers should come preinstalled with Qubes OS, have a constant time memcmp, constant time font rendering, etc?

> Because your in the minority

Fuck people with allergies, right? Let's only provide food with nuts and have them go through "additional hoops" to get food that won't kill them.

I do not think that this is a sound argument.

Re: Should random() be banned?

#205

Post by Khaine »

fanf2 wrote: post #185
Khaine wrote: post #136

Earlier quoted context omitted.

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.

Thanks! I don't know why I thought they used it.

Re: Should random() be banned?

#206

Post by esrauch »

fanf2 wrote: post #186
esrauch wrote: post #74

Earlier quoted context omitted.

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.

Can you explain more? I genuinely don't see any plausible threat model that a user running an Math.random() based custom algorithm password generator would be susceptible to, but the same algorithm using SecureRandom one is not. Both cases are so drastically better than manually thinking up a password that it's not even close.

I think if there's any gap it would be wrong roll your own password generator at all and you only use ones authored by security experts: just using SecureRandom instead of Random isn't going to somehow magically guarantee you didn't mess up another way and write a low-entropy password generator.

Re: Should random() be banned?

#207

Post by lmm »

h_anna_h wrote: post #190
lmm wrote: post #160

Earlier quoted context omitted.

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

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

It's about cost/benefit. As far as the compiler/framework knows, there's a 20% (say) chance that you've just introduced a major security bug into your program. Doesn't the benefit of requiring some explicit acknowledgement of that case outweigh the cost? You contrast "I" with "some idiot", but the evidence of the last 20+ years is that most programmers who think they can write secure code can't; if you make those kind of warnings only to people who opt-in to them, the very people who most need them will not get them.

Re: Should random() be banned?

#208

Post by lmm »

bscphil wrote: post #170
lmm wrote: post #160

Earlier quoted context omitted.

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

If by "predictable" all that's meant is "you can deterministically recreate every output bit generated by the function, forever, using a single value that represents the starting state of the function", then you can certainly have that and a secure RNG function. Just use ChaCha20's function with the key representing your seed.

That might be a good default, but where would the seed come from? You also need to make sure that the order in which random bits are read is deterministic, which is a lot harder than it sounds.

Re: Should random() be banned?

#209

Post by tgsovlerkhgsel »

bigiain wrote: post #144
tgsovlerkhgsel wrote: post #133

Earlier quoted context omitted.

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…

> I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications. Because for well over 99.99% of developers, cryptography is a “niche application”. I’ve never written crypto code I’ve deployed anywhere. If I need crypto, I use the highest level crypto library I can find that people I trust who _do_ know about crypto recommend. The only time I ever recall non crypt…

Cryptography is rare, but generating other data that needs to be unpredictable (e.g. session IDs, password reset tokens, random passwords getting generated, gift card codes, real-money gambling numbers) is quite common, I think.

And the default implementation of random() doesn't seem to be any faster than AES-CTR (which is the core of one form of secure PRNG).

Re: Should random() be banned?

#210

Post by tgsovlerkhgsel »

devlopr wrote: post #148
tgsovlerkhgsel wrote: post #133

Earlier quoted context omitted.

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…

Use the minimal amount of resources and scale up. If you need mostly random don't force cryptographic level random. It adds unnecessary processor cycles and reduces speed.

I benchmarked it, and AES-CTR is faster than `random()` on a machine with AES-NI.

That's my main point: It does _not_ seem to be meaningfully more expensive to use cryptographic randomness. Yes, you could build a faster non-cryptographic PRNG, but that's not what is done by the default library.

Post reply on HN