5 ms·
With any question like this, the path to an answer follows three intermediate questions: 1. Was there a security problem that resulted from the use of this ins
by matthewdgreen 2y ago
With any question like this, the path to an answer follows three intermediate questions:
1. Was there a security problem that resulted from the use of this insecure generator?
2. Were the developers who encountered this problem completely unreasonable and in the wrong, or were they simply non-(security)-experts who developed software that happened to have a security vulnerability?
3. If the latter, did the language/toolkit strongly encourage developers to use an insecure generator -- e.g., by making an insecure generator the default or "simpler" option (such as Random() instead of Random.secure()).
4. Is there some broad and general understanding that this toolkit is only intended for applications, such as monte-carlo testing or graphics rendering, where performance at the cost of security will always be the correct solution?
Given that the authors are able to offer several examples of real security vulnerabilities caused by developers using an insecure PRG, I'm going to read the answers as (1) Yes, (2) not unreasonable, (3) Yes, (4) I don't think so.
The decision to make insecure RNGs the default creates security vulnerabilities. This is demonstrable and has broad and unpredictable effects, given that developers are not security experts. The decision to make secure RNGs the default (easier path) has exactly one implication, which is that a small number of specialized applications will have slightly worse performance, performance that can easily be improved by making a conscious decision to remove the secure RNG.
- tedunangst 2y agoWait. Developers consciously chose to use this random because they believed it had a 64 bit seed? That's still wrong. It's irrelevant that it was truncated to only 32 bits.
- tptacek 2y agoThat may be, but having the default generator be non-cryptographic has been the conventional design choice in languages since the dawn of time. I would get the willies seeing security-sensitive code using "Random()" even if you told me in your language "Random()" was a CSPRNG.
- foooorsyth 2y agoI don’t think you should have to hold the entire canon of programming history in your head to avoid these types of footguns. Conventional design choices of the past that lead to bugs and security vulnerabilities should be replaced.
- swatcoder 2y agoI think most very experienced engineers would strongly disagree with you on (2) and would laugh at the usage characterization you make in (4). On #2: The difference between a PRNG and a cryptographically secure random number generator is foundational knowledge for software engineers, and there's (finally) a strong trade consensus that writing security-sensitive code has a higher bar of preparation and shouldn't be done naively. It's entirely unreasonable that someone writing a `uuid` implementation that's meant to be a cryptographically secure library for use by application developers wouldn't anticipate that their standard library would offer both and would prioritize the PRNG as its basic and most accessible generator. On #4: It's very rare that an application developer needs direct access to a cryptographically secure random number generator, especially because of that trade consensus that security-sensitive applications deserve expert care. In contrast, application developers are building test data pools, shuffling arrays, adding noise to signals, adding surprise to gameplay, writing and running reproducible tests, etc every day and naive use of a cryptographically secure random number generator in those contexts is easily paralyzing and catastrophic. The overhead can be order of magnitude in measure (which matters quite a lot in typical highly-repetitive/looped usage), and in some implementations it can introduce non-deterministic and potentially indefinite blocks on execution. And because they specifically can't be made deterministic by design, they significantly frustrate debug and test efforts that benefit from reproducibility. They're an essential tool in modern standard libraries, when they're needed in unusual cases, but are not suitable for naive everyday use at all.