31–40 of 214 posts
Earlier quoted context omitted.
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...
hmm I wonder what would happen if I enable this setting...
In our organization the policy is very simple. We have static method available throughout called CryptographyService.GenerateCsprngBytes(count = 64). All developers are aware that any security-sensitive requirements around entropy must use this method. It wraps the OS-level offering, and encourages a minimum reasonable level of entropy with a default count.
I don't see any reason to make it more complicated than this. Communication with your team is more important than writing check-in rules to prevent bad things from happening.
As for other uses of Math.Random, et. al., we don't have any official policy. Because we have clearly communicated the awareness that security-sensitive applications should always use the secure method, we don't need to add a bunch of additional bandaids on top. Enrich the team before the process.
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…
It's probably okay to leave the function as it is and just drill into people that if you're doing cryptography, you either need to know exactly what you're doing all the way down to the hardware or you need to leave it a task for somebody else more specialized than you. I, for one, never assume random() is cryptographically secure, but it might be because I grew up programming during the era where random was computed off of clock cycles since CPU startup because there wasn't much other cheap entropy to lay a hand on ("battery-backed onboard date clock?! Oh, look who has AKERS money!").
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.)
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.
The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes. Not true the other way round. And I'm inclined to say given how many misconceptions around randomness there are around, I don't think people are good at knowing whether they need secure randomness. The only possible justification for insecure randomness would be performance, but you'd need to generate a lot of rando…
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.
To answer this, we would need to know what you mean by random(). You haven't provided any language, library or other context.
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.
The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes. Not true the other way round. And I'm inclined to say given how many misconceptions around randomness there are around, I don't think people are good at knowing whether they need secure randomness. The only possible justification for insecure randomness would be performance, but you'd need to generate a lot of rando…
Earlier quoted context omitted.
It's also a good idea to give safer things shorter names. So make random() a CSPRNG (and an alias for SecureRandom() for people who want to be explicit) while InsecureFastRandom() is just what it says and has no other name. Then if you really need performance over unpredictability, it's there, but nobody is confused about what they're getting. And lazy people who don't like to type or pay close attention get the safe…
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.
For most domains secure random is a niche, not universally applicable.
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.)
Server-side folks generate random identifiers and shared secrets all the time. Yes, it's niche, but not "extremely" and you don't use a crypto library for this (you use secure random!)
Generally speaking, I'd agree the need for a cryptographicly secure random is niche in that it is limited to the implementation of specific libraries/functions that despite being widely used, should NOT be frequently re-implemented.