24 ms·
Should random() be banned?
- draw_down 6y agoWe did essentially that at my employer. I think the rationale is good, biasing toward a secure random function makes sense because the downside (as I understand it) is performance, but defaulting to insecure random has worse downsides. And if there ends up being a hot path where secure random is too inefficient, you can change it in that case. (This is in a context where a secure random function is readily at hand, when that's not the case, it could be trickier.)
- ThePadawan 6y agoI'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 iCopyPastedThisFromStackOverflowRandom()?
- cpeterso 6y agoFirefox 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/3ff133d19f87da2ba01ade55d6e7fdf0fc28b08c/js/xpconnect/src/nsXPConnect.cpp#1179 https://searchfox.org/mozilla-central/rev/3ff133d19f87da2ba0...
- wnevets 6y agohmm I wonder what would happen if I enable this setting...
- throwaway744678 6y ago*** wnevets quit (Connection reset by peer)
- makomk 6y agoYeah, and if I remember correctly one neat technique for exploiting security vulnerabilities in Firefox was to use them in order to set turn_off_all_security_so_that_viruses_can_take_over_this_computer to true, with obvious results.
- zrm 6y agoIt'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 one.
- cogman10 6y agoThat'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.
- njharman 6y agoMost 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.
- epanchin 6y agoAnd one would hope secure devs know which random to use, whereas gaming devs have no reason to know.
- josephg 6y agoLook 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.
- esrauch 6y agoEven 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 that generates the password that is literally just seconds-since-1970 would still be a good generator for almost all use cases.
- Spivak 6y agoSo you’re not big on bans but if you use dangerouslySetInnerHTML then it’s definitely not getting merged? Is that not a ban? Do you just not like when tooling enforces it?
- deleted 6y ago[deleted]
- dariusj18 6y agoThey said "without justification"
- ThePadawan 6y agoNo, as I said, it would raise a red flag. That flag can be lowered by justification, e. g. if you add types or constraints to only allow safe-enough parameters etc.
- deleted 6y ago[deleted]
- sp332 6y agoThe "ban" can be evaded by telling semgrep to ignore it for one line. https://semgrep.dev/docs/ignoring-findings/ https://semgrep.dev/docs/ignoring-findings/ This doesn't really scale though - if someone bans it with a different tool, you'd have to tell each tool to ignore this line.
- iratewizard 6y agoBeginner friendliness is something to remember, too. There are half a dozen words you could use to describe pseudoRandom(). Random() is easy for a first year or non-professional to remember.
- dariusj18 6y agoMost of the time the people who write and name the functions don't know it's not secure or safe. So you would still need to ban random when the new name is implemented.
- mannerheim 6y agoaccursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.11.0.0/docs/Data-ByteString-Internal.html https://hackage.haskell.org/package/bytestring-0.11.0.0/docs...
- deleted 6y ago[deleted]
- shadowgovt 6y agoI agree, with the caveat that use of random for cryptography is actually a domain specific use case. 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!").
- nicoburns 6y agoReact's dangerouslySetInnerHTML is indeed a good way of handling this kind of thing. Rust's `unsafe` is another example of the same approach.
- setr 6y agoI don't think rust's unsafe says anything about cryptographic security, beyond pointer-safety implications.
- nicoburns 6y agoNeither 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.
- andoriyu 6y agouhm 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.
- hyperman1 6y agoIsn't this just part of the world view of Rust? The word 'safe' in Rust has a very specific, technical meaning. 'unsafe' is simply code that is not automatically 'safe' in the Rust sense. A non-Rust developer sees safe/unsafe and gets worked up, but that just means that he should put his rust-colored glasses [*] on. This is not unusual in ICT, known for its colorful language. A non-ICTer hears 'black hat' and thinks about how cool and stylish the hat is. An ICTer hears 'hacker' and thinks about how cool and stylish the hack is. [*] Thanks, Raymond!
- suzzer99 6y agoI have required parameter to push our app to production called: YES_I_HAVE_ALREADY_MERGED_THE_LIB_REPOS_AND_WAITED_FOR_THEM_TO_COMPLETE_BEFORE_MERGING_THE_APP_REPOS Gets the point across and will still work when I'm long gone.
- Macha 6y agoThis 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 security team implemented an automated vulnerability scanner in our github enterprise instance, and it spammed comments and marked a review as requiring changes if it edited any merge request which touched a file which used java.util.Random. It lasted a day before the security team was made turn it off as on our team (and many others), literally 0 uses of random numbers were those requiring a secure random.
- jcelerier 6y ago> It lasted a day before the security team was made turn it off as on our team (and many others), literally 0 uses of random numbers were those requiring a secure random. can concur, currently approaching 400k SLOC of C++ in the repo. A few dozens different places crop up where random is needed (with a quick and dirty grepping). Literally 0% is for secure stuff. Most of it has to be as fast as possible (and very low quality, as it just needs to be random / noisy enough to look random for human perception)
- 1MoreThing 6y agoThe 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.
- extropy 6y agoThe 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.
- 6y ago
- ddlsmurf 6y agoIndeed this is a stupid debate. Knives help us in the kitchen but also sometimes stab people - should we ban knives ?
- madsbuch 6y agoIs 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.
- duckerude 6y agoIt is. The question was how often that's the case. If 50% of the uses of random() are bad, then getting those fixed may be worth the cost of annoying the authors of the legitimate 50%. It turned out to be much less useful than that. So they got rid of it.
- otabdeveloper4 6y agoNo, 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.)
- stickfigure 6y agoServer-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!)
- mreome 6y agoThere is a difference between generating these kind of IDs and writing the generator for these kinds of IDs. You shouldn't be rolling your own UUID generator if you don't fully understand the concerns/requirements in regards to your source of randomness. 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.
- josephg 6y agoI do this in nodejs all the time for IDs: require(‘crypto’).randomBytes(15).toString(‘base64’) Is this bad practice? Can you say more about why?
- kasperni 6y agoIf any, I would say it should be other way around. There are very few use cases outside of cryptography. So flag it if people uses a cryptographically secure PRNG directly. In almost all cases they would be better off finding a library that does what they need.
- zabzonk 6y agoTo answer this, we would need to know what you mean by random(). You haven't provided any language, library or other context.
- drewcoo 6y agoFlag it, sure, but don't ban it, bro! It is extremely useful for testing. It keeps this code simple and simpler tests are less buggy. Randomize a bunch of choices in input ranges and run a test. Need to re-run that exact scenario? Just set the seed to the same as the first go.
- duxup 6y ago> Isn’t random() often used for non-cryptographically sensitive operations? I was wondering just that, a little disappointed that there's no answers for anything in the article.
- antonyh 6y agoIt certainly is in my experience: everything from deterministically shuffling lists to Rogue-like map generation to audio/visual glitch & noise effects.
- tiborsaas 6y agoMeanwhile in graphics programming land: float rand(vec2 co){ return fract(sin(dot(co.xy,vec2(12.9898,78.233))) * 43758.5453); }
- LolWolf 6y agoHonestly, the one thing that got me into graphics (from physics and math) was just the incredible amount of: "you can literally do anything so long as you make it pretty in the end." I took that as a life philosophy and it's been pretty great so far.
- bobbylarrybobby 6y agoI assume you’ve seen John Carmack’s square root hack? What a beaut
- makeworld 6y agoCould someone explain this? How is it used, why does it take a vector as input, where do the magic numbers come from, etc.
- tiborsaas 6y agoIt's written in GLSL which is a C like language for shaders designed to be executed on the GPU. The 2D vector used for input is to represent pixel coordinates mapped from 0 to 1 or -1 to 1 on both axes. The magic numbers are nothing special, they are just large numbers to make the result unpredictable for the given input. The top level function is a fract which takes the fractional part of a number. So if the result of the inner computation is twisted enough it will be hard to trace it back to the original values. There are lots of variations for these one liners, most of the do a great job to produce noise.
- hyperman1 6y agorandom typically works by storing/modifying some state, so every call with the same argument results in different numbers. In shaders, the same code is executed in parallel for potentially every pixel. Storing state would mean pixels could only be calculated serially, slowing things down. Hence you need a random-ish function that depends only on its input. Very low RNG quality is not a blocker, as long as things look good. So in shaders you see a lot of random generators which simply take the pixel coordinate or something else that distinguishes 2 pixels and do some nonsense operations on them.
- klodolph 6y ago"Fix rate" is an interesting metric, but I don’t think it’s a good proxy for engineering value. When I see a false positive flagged by a compiler warning or static analyzer, sometimes I’ll fix it just because I’m not sure I want to turn off the rule. For example, I often use -Wunused-parameter with -Werror with Clang or GCC, and then just use (void)arg; to silence the false positives.
- aeturnum 6y agoIt seems like the "proper" solution to this problem would be to make all random number generators pull from the cryptographically secure randomness pool by default. If your random number needs are within what can be provided with strong guarantees, it doesn't seem like there's any reason to give you anything but strongly random numbers. People who need more random numbers per second than can be generated securely will simply have to pass explicit parameters indicating they want to stop getting high quality numbers. This would be easy to see in code review and highlight the choices being made.
- sobriquet9 6y agoThe problem is not random() itself, it's constructs like random() % n. Even if you replace random() with a CSPRNG, misuse won't go away.
- ddtaylor 6y agoI don't agree. I think Python and a few others do a good job by making random range based functions like `randrange` at curbing misuse.
- sobriquet9 6y agoFor cases where small statistical differences matter, like Monte-Carlo simulation, the overhead is non-trivial. Linear congruential generator is so simple it can be inlined by the compiler.
- zinkem 6y agoI most commonly use random() for generating names (e.g. docker's container names) and generating test inputs. I don't care about cryptographic safety in either case.
- iainmerrick 6y agoI wouldn’t imagine you care that much about speed either, right? Unless you’re generating gigabytes of random test data, maybe.
- tatersolid 6y agoBut you probably care about collisions in that case. The small state of a language-default insecure PRNG will make collisions much more likely. Especially if seeded by a clock. I have seen temp file name collisions cause data corruption in a real system because the default language RNG was used. Also infinite loops in a production system because random() was called in the same clock tick by two separate threads generating a handle value. Both wasted weeks of effort to pin down. random() should default to the system CSPRNG. Provide insecureFastRandom() for those who know they need it and it is safe for their use.
- bob1029 6y agoIt's all about the discipline of the team in the end... You can ban things all day, but it just takes 2 developers deciding they don't give a shit to code, review & merge that use-fast-random-for-session-token PR. There is more than 1 way to get something that is "random", so basic string matching for methods you don't like is certainly not a guarantee. 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.
- pdpi 6y ago> Communication with your team is more important than writing check-in rules to prevent bad things from happening. There's some subtlety here. This is sort of a security vs safety issue. Some people are just reckless, and that's a human problem that is best dealt with through a stern talking to (or, ultimately, termination) rather than technical measures. You'd require an oppressive amount of check-in rules in place to be even remotely effective at stopping this behaviour, and those would just make life miserable for everybody else. Some people are new to the team and/or just plain inexperienced, and it takes time for them to absorb all the standard practices so they can innocently cause trouble. Even veterans will make mistakes. Low friction guard rails can help keep those people from getting into too much trouble without being too onerous.
- nosefrog 6y agoAs an aside, I've worked with Dev Akhawe at Dropbox. Smart guy, knows his stuff :)
- f430 6y agoIs it possible to have something like random.org but without paying for it? say you want to build a lottery application, who can you rely on to make receive a very good random number generator at low cost? Should the government provide this for free to developers? Seems like its in everybody's interest to have a ~true random() function. Pokerstars uses lasers, someone else uses lava lamps, radio waves, what else? Also on a side note: how much do you think we have truly discovered the nature of "randomness"? Nassim Taleb says its not random if you run into somebody you know in the supermarket while thinking of them. Some physicists have likened it similar to newtonian others a more parallelian view. Why is it that some natural order emerges out of "randomness" out of a 52 card deck? How is it that a randomly swinging spot light in a dark room is able to "find" a plant that is also "randomly" placed in the room? Or the randomness of people's birth date and time emerging in lottery tickets? Or even more controversial, the fact that RNG is able to be seemingly influenced by the collective consciousness?
- admax88q 6y agoJust make Math.random() cryptographically secure, now all your apps are fixed, and no existing code broken. I can't imagine anything relying on Math.random() being "less" random than a CSRNG. Why must CSRNGs always have alternative obtuse APIs. We're still stuck on C style srand() + rand(). Cryptography is so ubiquitous now that failure to provide cryptographically secure random numbers should be viewed as a hardware flaw.
- throw0101a 6y agoSome folks purposely want random-ish results. When OpenBSD was changing the behaviour of its legacy POSIX random functions it was observed: This API is used in two patterns: 1. Under the assumption it provides good random numbers. This is the primary usage case by most developers. This is their expectation. 2. A 'seed' can be re-provided at a later time, allowing replay of a previous "random sequence", oh wait, I mean a deterministic sequence... They went through the code, especially the third-party packages/ports, to identify uses: > Differentiating pattern 1 from pattern 2 involved looking at the seed being given to the subsystem. If the software tried to supply a "good seed", and had no framework for re-submitting a seed for reuse, then it was clear it wanted good random numbers. Those ports could be eliminated from consideration, since they indicated they wanted good random numbers. > This left only 41 ports for consideration. Generally, these are doing reseeding for reproduceable effects during benchmarking. Further analysis may show some of these ports do not need determinism, but if there is any doubt they can be mindlessly modified as described below. * https://lwn.net/Articles/625562/ https://lwn.net/Articles/625562/
- nixpulvis 6y agoUnless I'm wrong, the only valid reason to not use a better random number generator is for performance / simplicity, which then demands benchmarks and evaluation.
- admax88q 6y agoThis is exactly what I mean about being stuck in the C mindset. You're looking at the problem though the lens of what this giant pile of ancient C software does. Why should newer languages take the same approach to APIs that these old code bases did? It's not like we're porting all those programs to JS. Those C APIs were written long before hardware could provide fast good randomness, heck even before cryptography was standard practice instead of a special use case. Not to mention in JS you can't even seed the random number generator. If you want predictable "random" numbers, you should have to jump through additional hoops. By default random numbers should be cryptographically secure. EDIT: It's also worth mentioning that from your reported dataset, 41 of 8800 programs analyzed used srand to get a repeatable set of "random" numbers. That's 0.47%. I'm happy to break less than half a percent of software if it helps prevent the far more ubiquitous failures of software using insecure random numbers.
- CivBase 6y agoMost 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?
- Macha 6y agoThere'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.
- rightbyte 6y ago> 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.
- account42 6y ago> 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
- CivBase 6y agoI 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.
- not2b 6y agoThere are many uses of random() that do not require cryptographic security: simulation, simulated annealing, sound synthesis, digital signal processing and the like. It would be a nuisance if developers of those kinds of software have to fight warnings because developers of completely different applications can't get it right.
- not2b 6y agoFurther, such users usually want to be able to repeat a test case: start from the same seed, get the same sequence. They don't want true randomness, they want a repeatable sequence with good statistical properties.
- antonyh 6y agoSeeded random is a glorious thing in the right circumstances. As an example, I've used it for 'random' testing sequences (jumbling up a list of inputs) but in a way I can later re-run EXACTLY the same test. It's also useful for other data generation tasks where the output can basically be saved as a seed, making it lightweight and easy to store - it could be written it on a scrap of paper in seconds. Maybe it's a bad name though - it should be called seededRandom() or semiRandom() or deterministicRandom(). Or perhaps it should be true random is no seed is set. Hard to know. Maybe the true random only needs to be the seed to a deterministic random and reset on a frequent basis in some cases. Then there's the category of casual random that doesn't matter, like random colours just for the sake of it. It doesn't need to be a secure safe random. And... assuming that any random function is truly random is a mistake anyway. Basing on hardware, and it may fail. Base it on software and where's the source of entropy. Add to that the possibility of bugs/defects in the implementation, and it's possible that it might not be as random as it needs to be. It's better to assume ALL RNGs are PRNGs, with the caveat that some are decidedly better than others. So no I wouldn't support a ban on it, nor would I support removing it from any language/runtime where it might be useful.
- dbcurtis 6y agoCame here to say this. I have spent a lot of time in hardware validation. Pseudo-random (explicitly NOT random) sequences are hugely useful. I once had a lights out server room of 60 servers whose entire purpose was to take skeletonized tests and a seed for a pseudo-random function and generate a test instance. That test instance went to one of a dozen test jigs. What was recorded was: pass/fail, the git sha of the template, and the seed. Any failing test could be reproduced at any time from just the git sha and the seed. True random would have killed that whole methodology.
- antonyh 6y agoThat sounds awesome, and the use of a repeatable random vital. Another example of random in a non-cryptography context where it's unpredictable under normal operation, but completely predictable when needed. If you wanted you could run the same test on all the test jigs with different seeds, safe in the knowledge that you could re-run all of them exactly again and again if required. Or you could add problematic seeds to a list for repeated retest with future versions. So much power and freedom!
- wilsonthewhale 6y agoNo mention of arc4random(3)? Seems like a solved problem in BSD land. The key takeaways I feel like are: 1. You want as simple of an interface as possible. arc4random(3) returns a single random 32 bit integer, or you can tell it to fill a buffer with them. 2. Just make it cryptographically secure. arc4random does it and it seems to be fine.
- iainmerrick 6y agoThe only problem is the weird name. It should just be random(). If there’s a not-so-good-but-faster version, call it fastRandom() or cheapRandom() or randomish() or something like that.
- deleted 6y ago[deleted]
- MauranKilom 6y ago> No mention of arc4random(3)? Seems like a solved problem in BSD land. Do you mean the "real" arc4random algorithm, or ChaCha20 (which is what arc4random actually is on OpenBSD)? See also: > OpenBSD was sufficiently dissatisfied with it that they replaced it with a generator based on the ChaCha20 stream cipher. https://www.pcg-random.org/other-rngs.html https://www.pcg-random.org/other-rngs.html
- f-word 6y ago"Banning" language features that are only "banned" when a linter is placed as a roadblock between the developer and the versioning system have to be the dumbest thing us developers have inflicted upon. How is this preventing me from recreating my own shit `random()` when it's entirely too late in the evening, deadlines are looming and the garbage office politics preclude me from disabling this asinine thing? I used to regularly trip on this damned reified rituals where we're only supposed to use a single type of quotes, or maybe using short vars like `i,j,k` on for loops and other garbage "rules" that might have sounded great when originally put in place but are horrible on a day-to-day basis. There's also the behavioral cost, I've noticed more and more people simply don't the code in code reviews anymore. Most feedback I get these days is stuff like "that's not supposed to be snake_case" or "a single space should be put between methods", and sometimes a glaring logic bug will crop up after 3 or 4 people who "approved" the review will gladly and openly admit _they_ _did_ _not_ _read_ _the_ _code_, and I think this is related to us overstressing the importance of all this tiny "form" misshaps and disregarding the "function" bits because it's harder to write a roadblock that checks for them.
- mytherin 6y ago> There's also the behavioral cost, I've noticed more and more people simply don't the code in code reviews anymore. Most feedback I get these days is stuff like "that's not supposed to be snake_case" or "a single space should be put between methods", and sometimes a glaring logic bug will crop up after 3 or 4 people who "approved" the review will gladly and openly admit _they_ _did_ _not_ _read_ _the_ _code_, and I think this is related to us overstressing the importance of all this tiny "form" misshaps and disregarding the "function" bits because it's harder to write a roadblock that checks for them. The goal of linters should be to ensure this doesn't happen. By turning non-compliant code into a test failure no reviewer attention ever needs to be wasted on formatting issues (which I fully agree is a complete waste of everyone's time). * If the tests pass, the formatting is correct. Great, reviewers have nothing to complain about. * If the tests don't pass, the formatting has to be fixed before the code will be merged. Code that doesn't pass the tests should never be merged in the first place. As a result, reviewers don't need to care as it has to be fixed anyway. Reviewers that still feel the need to point out formatting inconsistencies are likely just disinterested in providing genuine feedback, and would not have provided useful feedback regardless of the presence of linters.
- Quillbert182 6y agoSemi-unrelated question: How secure are the hardware random number generators on say, a raspberry pi. Would these sort of things be cryptographically secure?
- IcePic 6y agoI 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.
- Quillbert182 6y agoWould /dev/random be the combined entropy?
- IcePic 6y agoNo, that would be the output of some hash/crypto stream(s) that in turn gets seeded by all the entropy sources the machine can find, mixed together.
- nemo1618 6y agoThe root problem here is the notion that you need to choose between "strong and slow" randomness vs. "weak and fast" randomness. If every language's random() was strong and fast, most developers would never have to think about it. "Strong" randomness is often too slow because every time you ask for new entropy, you make a syscall. The solution is to use 32 bytes of strong randomness to seed a userspace CSPRNG. You can generate gigabytes of secure entropy per second in userspace. If you need deterministic entropy, just use the same seed. This isn't a one-size-fits-all solution, of course. If you only need to generate a few keys now and then, it's marginally safer to make a separate syscall for each of them. If you're targeting some tiny SoC, then sure, use xorshift instead. But what we care about is the common case, and right now the common case is a developer choosing the weak, deterministic RNG because it's faster and has a more convenient API and the secure RNG says "for cryptographic purposes" and well this usecase doesn't seem like cryptography, it's just a simple load balancer... That decision should never need to be made.
- moonchild 6y ago> The solution is to use 32 bytes of strong randomness to seed a userspace CSPRNG All cryptographic randomness generation should be performed by the kernel. You always have to think about security because if you don't think about security you're going to get hacked. By all means, name the insecure randomness generation function ‘insecure_random’. It does help. But secure-by-default helps you only marginally because when building secure software you don't get to just use the defaults; you have to think about what they're doing. You have to (for example) know and think about timing attacks even if you're using a cryptographic primitives library that's hardened against them, because it's really easy to introduce timing dependence into your own code and none of Daniel Bernstein or Tanja Lange’s careful designs will save you.
- nemo1618 6y agoThat's fair. There's no silver bullet for security. But we should not let the perfect be the enemy of the good. Everyone writing non-trivial systems should have some understanding of security; but the more components we make secure-by-default, the less those developers need to learn.
- harpiaharpyja 6y agoTL;DR: The answer is no, and here's how you can find a quantitative basis for that decision.
- cryptica 6y agoI 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.
- iphorde 6y agoOnly the uninformed ban things. random() is used by others that don't need it to be cryptographically secure.
- quantum_state 6y agoThe suggestion in and of itself displays ignorance ...
- lbblack 6y agoPeople ban programming functions? That is against the law for anyone respected and honest in the open source and scientific communities! THAT IS AGAINST THE 1ST AMENDMENT RIGHTS for any American citizen. Any human citizen within the sovereignty of this mighty country only for for Legendary souls is bought bought - but earned. With the hands of both Life and Death. And programming is the most divine magic of them all - which only holy warriors should be able to touch. Programming is a lost art and forgotten by anyone who is respected in the eyes of the Heavenly Courts. Learn something new tomorrow. Happy New Year Joe Biden, greatest president of the upcoming 21st century. Long live VALHALLA, and the mighty deliverer's of justice themselves. For the holy water which makes up Lake Tahoe, can only be touched by those granted access from a source of the Heavenly Courts. I believe and trust in my faith and my personal opinions. Lucas Bernard Black is actually really known by very few, but admired by many. Stay humble, stay rooted and shoot for the stars
- millstone 6y agoIs this referring to anything in particular, like POSIX random()? Or does it mean all non-CS PRNGs? If it's POSIX random() what is the proposed alternative?
- ThomasWinwood 6y agoThis is probably a hot take, but I don't think standard libraries should contain a random number generator. There is no globally correct choice of PRNG algorithm. If you need randomness, you should ask what kind of randomness - cryptography wants secure, Monte Carlo methods want fast, games can often benefit from N-dimensional equidistribution, etc. - and find a library specialised for that use case. A standard library function that nobody uses because there's always a better alternative elsewhere is a bad standard library function.
- wly_cdgr 6y agoNah, I think renaming is a better way to go, as others have suggested. "kindaRandom()" / "businessRandom()"
- brynet 6y agoTo quote Theo de Raadt's recent commit to OpenBSD's rand(3)/random(3) man pages, since people seem to be very confused here. +The deterministic sequence algorithm changed a number of times since +original development, is underspecified, and should not be relied upon to +remain consistent between platforms and over time. https://marc.info/?l=openbsd-cvs&m=161314944608164&w=2 https://marc.info/?l=openbsd-cvs&m=161314944608164&w=2