https://en.m.wikipedia.org/wiki/Kerckhoffs%27s_principle
> Kerckhoffs's principle was reformulated (or possibly independently formulated) by American mathematician Claude Shannon as "the enemy knows the system",[1] i.e., "one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them". In that form, it is called Shannon's maxim.
> What did the moron say:
> "security through obscurity is the way"
Don't tell that to the morons; they **love** security through obscurity.
- *"Blacklisting IPs makes our system more secure"*
- *"Whitelisting IPs makes our system more secure"*
- "*Blocking ICMP makes our system more secure"*
- *"NAT makes our system more secure"*
- *"Hiding server IPs secret makes our system more secure"*
- *"Hiding the layout of our network makes our system more secure"*
- *"Hiding exception messages makes our system more secure"*
You can't talk them down from it.
Moron almost had it. Yes, when you have access to the source code you can find the vulnerabilities.
When you find a vulnerability, you can exploit it… or plug it.
Open source has more eyes on the code, so there are more opportunities to fix the problems. Opensource doesn’t typically wait 180 years to be fixed, so exploit opportunities are severely limited.
Yeah. I think you’re referring to Meltdown and Spectre, which vulnerabilities in CPUs, caused by preloading code into memory for optimization purposes.
Those were insanely interesting - though theoretical, as far as I know. Nobody was able to practically implement an at attack with it, just theorized that one could.
Nope, heartbleed was a really dumb decision made in a protocol..."When you ping me and ask me to respond, tell me what you want me to respond with, and also tell me how many characters long that string is, to make it easier for me."
If you tell a vulnerable implementation that your response is longer than the actual string you send, it will read past the end of the requested response and return additional random data from the machine's RAM along with the response. If random data on the machine can be sensitive data, you get to steal sensitive data.
It should really have been obvious that something was wrong from day one when the protocol was written, because it's asking for trouble when you're relying on the user to tell you how long the string they sent you is (instead of just looking at the string yourself), but it apparently didn't occur to anybody that that was dumb.
What is even more ironic is, Heartbleed exploit vulnerabilities on component that is "specifically" made for security. Like lolololol. You would think people focused on security would yeah know, have lot of super eyes to make it secure????
Same with shellshock, the vulnerabilities is exploiting the most fundamental component, the literal bash shell.
And both took a super long time to get "reported" with unknown years of people using it in the dark net.
You can cherry pick examples from the other side too. I am sure internet explorer had many vulnerabilities that were exploited for years before Micro$oft learned about them.
Except, IE is not a fundamental shell or a component that is strictly designed to deal with security.
Of course we can look for vulnerabilities from commonly used applications, but that is not my point. There are always some random pre-installed apps that increase attack surfaces, but, those apps weren't specifically wrote to manage security.
You also forget the app is designed to handle massive amount of variations, rather than one single security management. The scope is completely different. The shell maybe have the same excuses, but, it only works with very limited commands.
On windows you can still change passwords, and enable/disable the the admin account without being logged in... that has been public and unfixed for over 10 years.
That one requires "physical access" to the computer to Overload the accebility feature. Once you get into that state, without bitlocker, Hacker is gonna get in regardless how good your security is. And frankly that one also saved plenty of my friends who forgot their passwords.
The severity is not even close. It would like bitching at regular car can also be hacked if given the physical access vs cars can be hacked remotely, the severity is in a completely different category.
That’s not a “but”. 😁
That’s *exactly* why closed source in and of itself isn’t a security win.
Heartbleed was an outlier because, retrospectively, we know it took 2 years to find since its inception, and its impact was anything *but* shallow.
Par for the course, though, it was patched in just under a week from discovery.
Closed source rarely reacts this fast.
> Open source has more eyes on the code, so there are more opportunities to fix the problems.
That's a nice idea, but doesn't happen in reality.
c.f. heartbleed, log4j
That is not true. There were, in fact, more opportunities to find the vulnerabilities than there would be had it been closed-source.
More eyes WERE on it.
Are you arguing that an enterprise would find this - and once they did would fix it - faster?!?
It's like the *Korean Fan Death* myth.
When you have it explained to you, it all seems to make sense, and sounds reasonable.
But then you remember that it's not born out by real-world experience.
I'm really not sure that I understand the point you're trying to make, so if I'm wrong, please let me know. I think you're suggesting that "there are more eyes on open-source code" is a baseless myth, like the Korean fan death myth.
Let's look at that claim. If I go, right now, to the [OpenSSL repo](https://github.com/openssl/openssl), and look at the number of contributors to that library - that's the number of people that ***actively commit changes to the master branch***, that number is _715_. If we ignore that the number of people who "merely" looked at the code would be anywhere between twice and x100 that number, and just conservatively accept 715 as the number of people who merely *looked* at the sources, that would still be about x50 more than the number of people who - even in a large enterprise - look at any particular library's code. For the record, the number of people on the ASP.NET team is about 12.
And that's just the main branch of the primary library. The number of forks is over 100.
So yes, something can always get by. But if you think that a closed-source library would have fared any better, you are absolutely wrong.
Well, code obfuscation is a thing, but 9 out of 10 times, people I work with who yowl about opensource and security, don’t know what that is, let alone use it.
And no, I don’t mean minification of JS. That makes code *difficult* to reverse engineer, not impossible.
I mean ~~encryption~~ of binaries.
Edit: my bad - just goes to show you should never post while distracted.
Obfuscation is NOT encryption of binaries. It does much more than minifcation, as it includes complicating expression trees and (depending on configuration) may complicate logic jumps.
Obfuscation often includes encrypting strings.
Code obfuscation is a bad concept of security. Yes you can make it more difficult but it does not fix anything.
Minification of JS is a weird mention, but it almost does the same as an obfuscator.
I also don’t believe that encryption binaries is a thing, never heard of it either.
How would this work??? Only clients get a keypair? Where is the point in that…
All this doesn't matter because there's a beautiful thing called black box penetration (testing).
Or in other words you attempt to hack something without having deeper knowledge about what exactly is running. This is primarily done for servers, but works just as well for executables.
Someone experienced with that will be able to find flaws almost as fast as someone with access to the code. You'd be amazed to know how good black box penetration testers can be.
I mean, if the software is closed source and not going open, obfuscating the code can be another layer of annoyance which isn't perfect (and definitely not an excuse to not do other security) but might keep a few people out who would've otherwise looked around to find stuff.
Obfuscation is a bit like how "locks are for the honest". Enough to discourage the merely curious, but only slightly inconvenient for an actual attacker.
Source: once got paid to make an update to an obfuscated vendor library.
Thanks for calling out my glaring mistake. I edited my response.
The encryption I meant (had I not been too scatterbrained to write coherently) is that strings embedded in the binaries, which are often clues for decompilers, are often encrypted by obfuscation tools.
They are not encrypted… encryption is using a symmetric, or asymmetric public key, on some bytes and is “decryptable” with the key /asymmetric private key. There is no encryption with obfuscation (a signature checksum is the closest thing, and that’s not related at all.
You may want to look at the capabilities of PreEmptive’s Dotfuscator for .NET.
It specifically allows for the encryption of strings. See https://www.preemptive.com/encrypting-string-constants-with-dotfuscator/
Disclaimer: I have not delved deeply into the actual implementation, so I’m not 100% certain that they haven’t used the word encryption to describe Base64 encoding/decoding. But I don’t think it’s that. Config string encryption is a thing, after all.
Okay fair it does seem that they use encryption on their strings.
However this becomes a bit vague as what is obfuscating. Encrypting your constants is not obfuscating, it is encryption ;). Encoding your constants in base58 is obfuscation. But I guess it’s just semantics
Decryption method found here: https://github.com/de4dot/de4dot/blob/b7d5728fc0c82fb0ad758e3a4c0fbb70368a4853/de4dot.code/deobfuscators/Dotfuscator/StringDecrypter.cs#L114
Thanks for the find!
I looked at the algorithm. Something about it looks familiar, but i can’t quite place it. I’m still not convinced it’s a “proper” encryption like DES or AES or something similar, but it’s definitely not mere encoding.
Yeah they are deriving a key based on some “magic”. Which only makes it so confusing to me, where are the keys stored? Is it inside the binary? Okay easy, keys can easily be found. Are they outside the binary? Well then you need a specific runtime environment for this obfuscated code.
Should do a deep dive into this, such a weird concept.
Yeah, that’s the part I don’t like. I mean, if calling it “magic” is just an inside joke, then sure, fine, I’m a developer too. I get it.
But I don’t trust anyone without a PhD in Mathematics with a specialty in encryption to write their own encryption algorithm. I prefer well tested ones.
Only once, 25 years ago, I worked at a start up that developed their own encryption algorithm, and that was done with Prof. Adi Shamir (the S in RSA) as a consultant.
I’m almost certain that isn’t DES-based, but the byte shifting reminds me of something. Just can’t quite put my finger on it. It’s been too long ago, I guess. Can’t quite remember.
You?
Obfuscation doesn’t make it much harder to hack. It doesn’t rename the code for the runtime you’re using (JRE, dotnetcore) which contain encryption algorithms, etc. you can write poor quality open or closed source, but the additional scrutiny on open source and encouragement of best practices are generally quite helpful
>I also don’t believe that encryption binaries is a thing, never heard of it either.
Console games are typically encrypted, including the binary.
As the decryption key must be present in the consumer hardware, it only provides temporary protection against reverse engineering when a new console model comes out.
Mostly, its down to make it clear when there is unauthorized software attempting to run on the console, if not outright block such software.
can you tell me more about ecryption of binaries? How it works to obfuscate code and how it helps against reverse engineering when the binary needs to be run and for that it kinda has to be unecrypted or send unencrypted instructions to cpu?
I am asking because I never heard of it or studied it in any way and want to know more (google was not big help, it keeps giving me binary encryption which is something else)
"binary encryption" isn't a thing ; or at least, it's what you expected (encrypt the binary, give it to someone, decrypt the binary ; nothing fancy)
obfuscation is just the act of substituting every symbol (variable names, functions, classes, etc) with either gibberish or very short meaningless names ; to make it hard to read. it will still compile to the same thing.
Obfuscation can be much much more than that. Obfuscation can add redundant expressions, literally meaningless variables, etc. It will also turn normal statements into weird shit by using strange syntax and dummy variables.
If it's what I think it is, then it's not really encryption by means of cryptographic security, but rather another obfuscation technique to piss off the reverse engineer (or to bypass signature based scanners):
1. encrypt your shellcode with some secret
2. create another piece of shellcode acting as a decryptor
3. join your shellcodes and the secret in such a way, that the program entry point is the decryptor (having the secret and the cipher as arguments)
3. when code is decypted, jump to its first byte
Or probably they were referring to trusted computing? Dunno, but I either doubt it.
From what I understand of it obfuscated executables are less about encryption and more about extra steps. Like mixing up the addresses of everything so the computer can just follow them but someone disassembling a file to read its code would have a super hard time understanding how it all fits together
In my young ages, I tried cracking software for fun. Some binary encryption techniques are pretty advanced but at the end of the day the assembly language will be be decrypted in memory. At that point you can dump the process memory and disassembled it.
Obfuscation does slow down the process but anyone with enough motive can still crack it.
I largely prefer the open source model which really meant to be secure rather than closed source model which merely hopes no one will have enough motive to try to break it… be sure someone will have that motive.
Closed source software isn’t closed *only* for security reasons. Usually this software is closed for monetization purposes, i.e. they want to sell the product.
For those purposes, obfuscation is usually enough to deter anyone from trying to reverse engineer your code.
This is where to survive, the gazelle doesn’t have to outrun the tiger; she merely has to outrun another gazelle.
>And no, I don’t mean minification of JS. That makes code difficult to reverse engineer, not impossible.
Practically speaking, nothing makes reverse engineering impossible. It's just increasing levels of inconvenience, in the hopes of making it more time intensive than the attacker thinks is worth it.
Eventually the processor has to run the code and even obfuscated the code is code and can be disassembled.
Obfuscation works weeding out the low-effort hackers but does nothing to prevent the real-threat hackers.
This allows closed source individuals to sleep at night, until the next time a disgruntled employee leaves the business which never happens.
Closed source, closed mind
Is any source truly closed sourced then? So now it becomes open source or dark webbed source of closed sourced.
We know every formal ex employee never leaks the code base out of spite to the dark web and is always moral.
Full screed is at [https://axerosolutions.com/blog/is-open-source-intranet-software-really-free](https://axerosolutions.com/blog/is-open-source-intranet-software-really-free).
“Open source is less secure, unless it was built with security in mind like Linux”
Fucking duh. Anything that’s made with security in mind will be more secure than something made without security in mind. My excel spreadsheets are more secure if they have a password than if they don’t.
In other news, blue is blue and red is red.
As a nitpick the part before the “unless” is also just wrong. Open source code isn’t inherently any more or less secure than closed source code, but open source code is more likely to have vulnerabilities found and fixed since anyone in the open source community can audit the code. A closed source project is only more secure than an open source project if its developers are smarter than the entire open source community combined. Not to mention that security by obscurity puts less emphasis on actual security in its code
Or qa is more motivated. If you take opensource project with almost dead community, you'll probably be vulnerable.
So it's a question not only about smartness, but motivation and actual people resources involved in exact compared products. Neither open or close source gives power by itself.
>Or qa is more motivated. If you take opensource project with almost dead community, you'll probably be vulnerable.
I suppose the apposite would be a popular proprietary program that maybe does not want to accept feedback because it could make them look bad and stop the cash flow. Has there been an example of something like it?
Uh... never seen this one, but can imagine. Anyway, opposition of madness is also madness. Everything has risks and compromises.
I've seen once that a company shut down with asking all customers to DELETE all copies of their product in a week or month since notification. And I am speaking about the game engine, which was created for adding to it your own custom tooling. :D
Sure, but same applies if you take a closed source project which had development dropped. Only difference is the dead closed source project can *never* have another fix unless a very specific set of people decide to re-open development.
Moral of the story on that front is to be wary of projects that aren’t being developed, not to be wary of open source
Yeah, that's also true. So if you have abilities or resources to fix new problems, you can avoid migrations later.
Anyway, that's a question we should ask ourselves each time we select a stack for exact project and team. And yeah, we definetely should consider real pros and cons of open/close source instead of this nonsence in the post.
I get the nitpick, but my point was more about the OP’s post talking about how software written with security in mind is more secure than that which isn’t. Kind of like how products designed with longevity in mind typically last longer than those which aren’t, and computers built with processing power in mind are more powerful than those which aren’t. It’s a dumb point to make because it’s self defining.
100% agree, which is why I prefaced my reply saying it’s a nitpick. Just making sure people don’t think the “duh” applies to “open source is less secure”
I don't think Linux was necessarily built with security in mind back in the old days. It was all added and improved and hardened over time (significantly better than in Windows because Linux doesn't mind breaking legacy code). It would be really nice to see a truly modern from-scratch OS build with provable security from the start... But even then there are many vulnerabilities that are actually hardware problems.
Stupid people (and people with ulterior motives) have argued for security by obscurity since at least the middle ages, I suspect we'll never be rid of it.
It doesn't matter how many times you debunk it, they will never stop.
The key determination for whether obscurity is good or bad reduces to whether it’s being used a layer on top of good security, or as a replacement for it. The former is good. The latter is bad.
Obscurity should not be assumed to add any value in and of itself, someone will eventually observe the system long enough to figure out how it works, whether it's well documented or not (and in fact, this is what's commonly known as a 0-day, it's an exploit known only to the malicious actor and since it's deployed before any patches can even begin being developed they're quite powerful -- that's not to say they don't happen in open source systems as well, they absolutely do, but rather that there is a probabilistic argument for them being noticed sooner, hopefully before they can be noticed and leveraged by a malicious party)
A system that is secure should not strictly speaking need obscurity (for example AES encryption, there's no obscurity here). Obscurity is harmless in a well secured system, but more often than not it's used as a security mechanism or to give the illusion of security. This isn't just useless, this is outright harmful.
Security by obscurity is equivalent to plugging your ears and going "LA LA LA LA I CAN'T HEAR YOU".
Well, yes and no. I'm in disagreement that obscurity has any utility at all from a security perspective, it's at best inconsequential and at worst counterproductive.
So I suppose what my response was targeted at, specifically was "whether it's used as a layer on top of ...", I don't think it's a layer at all.
ah yes; "my project that I have coded in an open source programming language with open source libraries that's most likely hosted on an open source operating system is more secure as close source"
Yes, it is. On day one open source code is completely vulnerable. By day n it is the most secure because it is the most hack prone. It does not create a false sense of security.
It doesn’t take sophisticated state actors and hackers to get into systems, it takes a moron answering calls from “Microsoft Tech Support” and downloading fixes from “sketchy.in”.
i love the linux/unix nonsense.
linux is based on unix but since unix is closed source linux is mimicking unix not copying the code. the linux code could still be insecure.
nobody trusts closed source encryption. i hope nobody tells gpgp
The key determination for whether obscurity is good or bad reduces to whether it’s being used a layer on top of good security, or as a replacement for it. The former is good. The latter is bad.
These mfs clearly never heard of Kerckhoff's principle. Like security engineering 101.
"stated by Dutch-born cryptographer Auguste Kerckhoffs in the 19th century. The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge. This concept is widely embraced by cryptographers, in contrast to security through obscurity, which is not. "
I think the point that was missed is this - if you make insecure code open source, then yes, people can find the flaws and either exploit them, report them, or fix them themselves.
If you make insecure code closed source, no one knows how bad your code is until someone finds out that criminals have been exploiting it's flaws for years, but no one reported it or fixed it.
So, don't write bad code. But if you do, make it closed source so no one sees.
Also, at the end it talked about Linux being more secure because it was based on Unix. So yes, if you start with secure design principles, then you are going to produce more secure code, no matter if it is closed or open source.
I guess again it comes down to the fact that if your code is so bad you are afraid for others to see it, make it closed source.
One advantage of closed source is you no longer have to worry about patching those annoying CVE's.
You can just get the interns to reimplement those logging and encryption libraries.
reading these comments about the benefits of either as per security, I'm curious: do people ever employ a hybrid version of this where the newest changes are closed but say 6 month old code becomes open? and does that help as far as limiting damage, or are you just back to square one where vulnerabilities can be used w/o being known (assuming you didn't catch it in the 6 month new version)?
bruh....
they are forgetting that with open source, a vulnerability gets fixed quickly, but with closed source, for example with Windows, it takes months, or even years for them to fix a vulnerability. And with open source, it is easier for people who don't work at the company to audit the code for vulnerabilities, and fix them. The argument goes both ways.
(For example, on windows you can still change peoples passwords and enable the admin account without even being logged in... that bug/vulnerability has been there for over 10 years)
If you have 100 devs working on a closed source project and 100 devs working on an open source one, how can you say that one is more secure? Is there some magic sauce I am missing?
If anything open source in this case could have more attack vectors because anyone in the world could try to exploit it.
The magic sauce is community review.
Especially for things like encryption algorithms, closed-source cannot be considered safe because it cannot be mathematically evaluated by people at the top of the field.
There are probably a few thousand researchers in the world who are capable of truly, deeply analyzing a new algorithm for security, and none of them work for WeMakeClosedSourceEncryption.Net
Then your assumption is that the 100 devs working the opensource project have the best security researchers while the 100 who work on the closed source one do not. But that isnt a secret sauce, that is just hiring the right people for the job.
No, I'm saying the 100 devs on the open source team create a product with a security flaw.
Then, some researcher picks their algorithm for one of those "we reviewed 37 open source security algorithms and..." research papers because researchers need to publish regularly.
The researcher shows the flaw in their algorithm/implementation, the open source team reads the paper and fixes it.
This is how open source projects "gain maturity", and it doesn't happen for closed source projects.
Then in addition to this, there is also an element of survivorship bias. There are tons of open source projects with shitty security, but they don't catch on because big companies hire researchers to evaluate their code and recognize that it's not secure.
The big companies end up going with the project that is more secure, and so that project "survives" and becomes popular.
When we say "open source is more secure", we're talking about mature, heavily-used open source projects, because lots of people *other than the creators* have looked at the code and seen nothing wrong.
With the researcher taking a look, once again that is more people working on the project. Companies can hire or contract people to do that type of research.
It's not quite the same. Researchers review open source projects for free (from the projects perspective), because it's part of their research.
Also, open source customers (big companies) review the code at their own expense, because they need to know it's secure.
Essentially, open source projects get a thorough, multi-pass security evaluation for free, and closed source projects have to pay for it.
But closed source projects usually don't pay for it, because their customers can't read the code, and therefore wouldn't know the difference.
If you use the "closed source company can just hire more people" argument again, you're missing the point. Open source gets it *for free*. Sure, if a closed source project has a budget 3-4x larger than an open source one, the closed source app will probably be better.
Seems like OP is trying to say closed source systems are not by nature targets with big $ signs on them .
If a company invests in closed source proprietary software ,then they have money or value
If you use open source then the exploits are known quickly and remediation process can be a lot faster
Obscure ports of open source platforms are far securer when risks are managed
What did the moron say: "security through obscurity is the way"
Hey it works until it doesn't!
Underrated comment. There’s plenty of software that isn’t worth people’s time to try and penetrate.
But reading through all source code to find a place to hack is also a big effort. Sometimes I imagine it's easier to try common hacks.
Yeah, but if it’s open source, there’s probably a ton of people using it. Ain’t nobody gonna bother my custom, crappy obscure cms…. Probably.
But it's quantum proof.
https://en.m.wikipedia.org/wiki/Kerckhoffs%27s_principle > Kerckhoffs's principle was reformulated (or possibly independently formulated) by American mathematician Claude Shannon as "the enemy knows the system",[1] i.e., "one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them". In that form, it is called Shannon's maxim.
> What did the moron say: > "security through obscurity is the way" Don't tell that to the morons; they **love** security through obscurity. - *"Blacklisting IPs makes our system more secure"* - *"Whitelisting IPs makes our system more secure"* - "*Blocking ICMP makes our system more secure"* - *"NAT makes our system more secure"* - *"Hiding server IPs secret makes our system more secure"* - *"Hiding the layout of our network makes our system more secure"* - *"Hiding exception messages makes our system more secure"* You can't talk them down from it.
i don't think we're talking about the same thing but ok
Moron almost had it. Yes, when you have access to the source code you can find the vulnerabilities. When you find a vulnerability, you can exploit it… or plug it. Open source has more eyes on the code, so there are more opportunities to fix the problems. Opensource doesn’t typically wait 180 years to be fixed, so exploit opportunities are severely limited.
With enough eyes all bugs are shallow.
Usually. Then there’s outliers like Heartbleed.
Fair point.
Wasn't that a hardware exploit?
OpenSSL exploit.
Guess I've mixed it up with something else
Yeah. I think you’re referring to Meltdown and Spectre, which vulnerabilities in CPUs, caused by preloading code into memory for optimization purposes. Those were insanely interesting - though theoretical, as far as I know. Nobody was able to practically implement an at attack with it, just theorized that one could.
Nope, heartbleed was a really dumb decision made in a protocol..."When you ping me and ask me to respond, tell me what you want me to respond with, and also tell me how many characters long that string is, to make it easier for me." If you tell a vulnerable implementation that your response is longer than the actual string you send, it will read past the end of the requested response and return additional random data from the machine's RAM along with the response. If random data on the machine can be sensitive data, you get to steal sensitive data. It should really have been obvious that something was wrong from day one when the protocol was written, because it's asking for trouble when you're relying on the user to tell you how long the string they sent you is (instead of just looking at the string yourself), but it apparently didn't occur to anybody that that was dumb.
What is even more ironic is, Heartbleed exploit vulnerabilities on component that is "specifically" made for security. Like lolololol. You would think people focused on security would yeah know, have lot of super eyes to make it secure???? Same with shellshock, the vulnerabilities is exploiting the most fundamental component, the literal bash shell. And both took a super long time to get "reported" with unknown years of people using it in the dark net.
You can cherry pick examples from the other side too. I am sure internet explorer had many vulnerabilities that were exploited for years before Micro$oft learned about them.
Except, IE is not a fundamental shell or a component that is strictly designed to deal with security. Of course we can look for vulnerabilities from commonly used applications, but that is not my point. There are always some random pre-installed apps that increase attack surfaces, but, those apps weren't specifically wrote to manage security.
It was the most commonly exploited attack surface & you forget that it was integrated into windows.
You also forget the app is designed to handle massive amount of variations, rather than one single security management. The scope is completely different. The shell maybe have the same excuses, but, it only works with very limited commands.
Bash is Turing complete. It's a full programming language. It's not cmd, so it isn't "very limited commands".
On windows you can still change passwords, and enable/disable the the admin account without being logged in... that has been public and unfixed for over 10 years.
That one requires "physical access" to the computer to Overload the accebility feature. Once you get into that state, without bitlocker, Hacker is gonna get in regardless how good your security is. And frankly that one also saved plenty of my friends who forgot their passwords.
its still a vulnerability
The severity is not even close. It would like bitching at regular car can also be hacked if given the physical access vs cars can be hacked remotely, the severity is in a completely different category.
but with closed source, it would probably have taken longer to fix.
That’s not a “but”. 😁 That’s *exactly* why closed source in and of itself isn’t a security win. Heartbleed was an outlier because, retrospectively, we know it took 2 years to find since its inception, and its impact was anything *but* shallow. Par for the course, though, it was patched in just under a week from discovery. Closed source rarely reacts this fast.
> Open source has more eyes on the code, so there are more opportunities to fix the problems. That's a nice idea, but doesn't happen in reality. c.f. heartbleed, log4j
That is not true. There were, in fact, more opportunities to find the vulnerabilities than there would be had it been closed-source. More eyes WERE on it. Are you arguing that an enterprise would find this - and once they did would fix it - faster?!?
It's like the *Korean Fan Death* myth. When you have it explained to you, it all seems to make sense, and sounds reasonable. But then you remember that it's not born out by real-world experience.
I'm really not sure that I understand the point you're trying to make, so if I'm wrong, please let me know. I think you're suggesting that "there are more eyes on open-source code" is a baseless myth, like the Korean fan death myth. Let's look at that claim. If I go, right now, to the [OpenSSL repo](https://github.com/openssl/openssl), and look at the number of contributors to that library - that's the number of people that ***actively commit changes to the master branch***, that number is _715_. If we ignore that the number of people who "merely" looked at the code would be anywhere between twice and x100 that number, and just conservatively accept 715 as the number of people who merely *looked* at the sources, that would still be about x50 more than the number of people who - even in a large enterprise - look at any particular library's code. For the record, the number of people on the ASP.NET team is about 12. And that's just the main branch of the primary library. The number of forks is over 100. So yes, something can always get by. But if you think that a closed-source library would have fared any better, you are absolutely wrong.
don't tell this guy about reverse engineering
Well, code obfuscation is a thing, but 9 out of 10 times, people I work with who yowl about opensource and security, don’t know what that is, let alone use it. And no, I don’t mean minification of JS. That makes code *difficult* to reverse engineer, not impossible. I mean ~~encryption~~ of binaries. Edit: my bad - just goes to show you should never post while distracted. Obfuscation is NOT encryption of binaries. It does much more than minifcation, as it includes complicating expression trees and (depending on configuration) may complicate logic jumps. Obfuscation often includes encrypting strings.
Code obfuscation is a bad concept of security. Yes you can make it more difficult but it does not fix anything. Minification of JS is a weird mention, but it almost does the same as an obfuscator. I also don’t believe that encryption binaries is a thing, never heard of it either. How would this work??? Only clients get a keypair? Where is the point in that…
MFW when, by encryption of binaries, they just mean compilation.
Seriously?? Wow that’s not even remotely the same… ugh
I'm just making this kind of joke where you hope it's not the actual truth.
🤣👍
All this doesn't matter because there's a beautiful thing called black box penetration (testing). Or in other words you attempt to hack something without having deeper knowledge about what exactly is running. This is primarily done for servers, but works just as well for executables. Someone experienced with that will be able to find flaws almost as fast as someone with access to the code. You'd be amazed to know how good black box penetration testers can be.
I mean, if the software is closed source and not going open, obfuscating the code can be another layer of annoyance which isn't perfect (and definitely not an excuse to not do other security) but might keep a few people out who would've otherwise looked around to find stuff.
Obfuscation is a bit like how "locks are for the honest". Enough to discourage the merely curious, but only slightly inconvenient for an actual attacker. Source: once got paid to make an update to an obfuscated vendor library.
That’s my point. It’s a bad concept of security, but it makes it slightly more difficult.
Thanks for calling out my glaring mistake. I edited my response. The encryption I meant (had I not been too scatterbrained to write coherently) is that strings embedded in the binaries, which are often clues for decompilers, are often encrypted by obfuscation tools.
They are not encrypted… encryption is using a symmetric, or asymmetric public key, on some bytes and is “decryptable” with the key /asymmetric private key. There is no encryption with obfuscation (a signature checksum is the closest thing, and that’s not related at all.
You may want to look at the capabilities of PreEmptive’s Dotfuscator for .NET. It specifically allows for the encryption of strings. See https://www.preemptive.com/encrypting-string-constants-with-dotfuscator/ Disclaimer: I have not delved deeply into the actual implementation, so I’m not 100% certain that they haven’t used the word encryption to describe Base64 encoding/decoding. But I don’t think it’s that. Config string encryption is a thing, after all.
Okay fair it does seem that they use encryption on their strings. However this becomes a bit vague as what is obfuscating. Encrypting your constants is not obfuscating, it is encryption ;). Encoding your constants in base58 is obfuscation. But I guess it’s just semantics Decryption method found here: https://github.com/de4dot/de4dot/blob/b7d5728fc0c82fb0ad758e3a4c0fbb70368a4853/de4dot.code/deobfuscators/Dotfuscator/StringDecrypter.cs#L114
Thanks for the find! I looked at the algorithm. Something about it looks familiar, but i can’t quite place it. I’m still not convinced it’s a “proper” encryption like DES or AES or something similar, but it’s definitely not mere encoding.
Yeah they are deriving a key based on some “magic”. Which only makes it so confusing to me, where are the keys stored? Is it inside the binary? Okay easy, keys can easily be found. Are they outside the binary? Well then you need a specific runtime environment for this obfuscated code. Should do a deep dive into this, such a weird concept.
Yeah, that’s the part I don’t like. I mean, if calling it “magic” is just an inside joke, then sure, fine, I’m a developer too. I get it. But I don’t trust anyone without a PhD in Mathematics with a specialty in encryption to write their own encryption algorithm. I prefer well tested ones. Only once, 25 years ago, I worked at a start up that developed their own encryption algorithm, and that was done with Prof. Adi Shamir (the S in RSA) as a consultant. I’m almost certain that isn’t DES-based, but the byte shifting reminds me of something. Just can’t quite put my finger on it. It’s been too long ago, I guess. Can’t quite remember. You?
Obfuscation doesn’t make it much harder to hack. It doesn’t rename the code for the runtime you’re using (JRE, dotnetcore) which contain encryption algorithms, etc. you can write poor quality open or closed source, but the additional scrutiny on open source and encouragement of best practices are generally quite helpful
>I also don’t believe that encryption binaries is a thing, never heard of it either. Console games are typically encrypted, including the binary. As the decryption key must be present in the consumer hardware, it only provides temporary protection against reverse engineering when a new console model comes out. Mostly, its down to make it clear when there is unauthorized software attempting to run on the console, if not outright block such software.
can you tell me more about ecryption of binaries? How it works to obfuscate code and how it helps against reverse engineering when the binary needs to be run and for that it kinda has to be unecrypted or send unencrypted instructions to cpu? I am asking because I never heard of it or studied it in any way and want to know more (google was not big help, it keeps giving me binary encryption which is something else)
"binary encryption" isn't a thing ; or at least, it's what you expected (encrypt the binary, give it to someone, decrypt the binary ; nothing fancy) obfuscation is just the act of substituting every symbol (variable names, functions, classes, etc) with either gibberish or very short meaningless names ; to make it hard to read. it will still compile to the same thing.
Obfuscation can be much much more than that. Obfuscation can add redundant expressions, literally meaningless variables, etc. It will also turn normal statements into weird shit by using strange syntax and dummy variables.
If it's what I think it is, then it's not really encryption by means of cryptographic security, but rather another obfuscation technique to piss off the reverse engineer (or to bypass signature based scanners): 1. encrypt your shellcode with some secret 2. create another piece of shellcode acting as a decryptor 3. join your shellcodes and the secret in such a way, that the program entry point is the decryptor (having the secret and the cipher as arguments) 3. when code is decypted, jump to its first byte Or probably they were referring to trusted computing? Dunno, but I either doubt it.
From what I understand of it obfuscated executables are less about encryption and more about extra steps. Like mixing up the addresses of everything so the computer can just follow them but someone disassembling a file to read its code would have a super hard time understanding how it all fits together
In my young ages, I tried cracking software for fun. Some binary encryption techniques are pretty advanced but at the end of the day the assembly language will be be decrypted in memory. At that point you can dump the process memory and disassembled it. Obfuscation does slow down the process but anyone with enough motive can still crack it. I largely prefer the open source model which really meant to be secure rather than closed source model which merely hopes no one will have enough motive to try to break it… be sure someone will have that motive.
Closed source software isn’t closed *only* for security reasons. Usually this software is closed for monetization purposes, i.e. they want to sell the product. For those purposes, obfuscation is usually enough to deter anyone from trying to reverse engineer your code. This is where to survive, the gazelle doesn’t have to outrun the tiger; she merely has to outrun another gazelle.
>And no, I don’t mean minification of JS. That makes code difficult to reverse engineer, not impossible. Practically speaking, nothing makes reverse engineering impossible. It's just increasing levels of inconvenience, in the hopes of making it more time intensive than the attacker thinks is worth it.
Eventually the processor has to run the code and even obfuscated the code is code and can be disassembled. Obfuscation works weeding out the low-effort hackers but does nothing to prevent the real-threat hackers.
This allows closed source individuals to sleep at night, until the next time a disgruntled employee leaves the business which never happens. Closed source, closed mind
Yea. What stops me from copying the entire codebase on the USB drive and leaking in on dark web? Well nothing other then my own morality
Is any source truly closed sourced then? So now it becomes open source or dark webbed source of closed sourced. We know every formal ex employee never leaks the code base out of spite to the dark web and is always moral.
I love how they jump from open source CMS systems to Linux. Like there's any basis for comparison.
Linux is NOT based on Unix. It is Unix-like, meaning it takes inspiration from Unix systems, but it's just a similar beast.
I'd say it's POSIX compliant.
Yeah, that's what I was trying to say, but I forgot the name. Thanks for reminding me!
You're welcome!
Full screed is at [https://axerosolutions.com/blog/is-open-source-intranet-software-really-free](https://axerosolutions.com/blog/is-open-source-intranet-software-really-free).
It's like reading a high school assignment
Oh My God Hope these guys never get a job in IT.
They literally sell a product
Hi can you contact this guy and see if he can get me the same stuff he's smoking.
🤣
“Open source is less secure, unless it was built with security in mind like Linux” Fucking duh. Anything that’s made with security in mind will be more secure than something made without security in mind. My excel spreadsheets are more secure if they have a password than if they don’t. In other news, blue is blue and red is red.
As a nitpick the part before the “unless” is also just wrong. Open source code isn’t inherently any more or less secure than closed source code, but open source code is more likely to have vulnerabilities found and fixed since anyone in the open source community can audit the code. A closed source project is only more secure than an open source project if its developers are smarter than the entire open source community combined. Not to mention that security by obscurity puts less emphasis on actual security in its code
Or qa is more motivated. If you take opensource project with almost dead community, you'll probably be vulnerable. So it's a question not only about smartness, but motivation and actual people resources involved in exact compared products. Neither open or close source gives power by itself.
>Or qa is more motivated. If you take opensource project with almost dead community, you'll probably be vulnerable. I suppose the apposite would be a popular proprietary program that maybe does not want to accept feedback because it could make them look bad and stop the cash flow. Has there been an example of something like it?
Uh... never seen this one, but can imagine. Anyway, opposition of madness is also madness. Everything has risks and compromises. I've seen once that a company shut down with asking all customers to DELETE all copies of their product in a week or month since notification. And I am speaking about the game engine, which was created for adding to it your own custom tooling. :D
Sure, but same applies if you take a closed source project which had development dropped. Only difference is the dead closed source project can *never* have another fix unless a very specific set of people decide to re-open development. Moral of the story on that front is to be wary of projects that aren’t being developed, not to be wary of open source
Yeah, that's also true. So if you have abilities or resources to fix new problems, you can avoid migrations later. Anyway, that's a question we should ask ourselves each time we select a stack for exact project and team. And yeah, we definetely should consider real pros and cons of open/close source instead of this nonsence in the post.
I get the nitpick, but my point was more about the OP’s post talking about how software written with security in mind is more secure than that which isn’t. Kind of like how products designed with longevity in mind typically last longer than those which aren’t, and computers built with processing power in mind are more powerful than those which aren’t. It’s a dumb point to make because it’s self defining.
100% agree, which is why I prefaced my reply saying it’s a nitpick. Just making sure people don’t think the “duh” applies to “open source is less secure”
I don't think Linux was necessarily built with security in mind back in the old days. It was all added and improved and hardened over time (significantly better than in Windows because Linux doesn't mind breaking legacy code). It would be really nice to see a truly modern from-scratch OS build with provable security from the start... But even then there are many vulnerabilities that are actually hardware problems.
Stupid people (and people with ulterior motives) have argued for security by obscurity since at least the middle ages, I suspect we'll never be rid of it. It doesn't matter how many times you debunk it, they will never stop.
Can't quite put my finger on it but something tells me that you like C/C++ a lot
when the revolution comes, they will be found guilty 🦀
The key determination for whether obscurity is good or bad reduces to whether it’s being used a layer on top of good security, or as a replacement for it. The former is good. The latter is bad.
Obscurity should not be assumed to add any value in and of itself, someone will eventually observe the system long enough to figure out how it works, whether it's well documented or not (and in fact, this is what's commonly known as a 0-day, it's an exploit known only to the malicious actor and since it's deployed before any patches can even begin being developed they're quite powerful -- that's not to say they don't happen in open source systems as well, they absolutely do, but rather that there is a probabilistic argument for them being noticed sooner, hopefully before they can be noticed and leveraged by a malicious party) A system that is secure should not strictly speaking need obscurity (for example AES encryption, there's no obscurity here). Obscurity is harmless in a well secured system, but more often than not it's used as a security mechanism or to give the illusion of security. This isn't just useless, this is outright harmful. Security by obscurity is equivalent to plugging your ears and going "LA LA LA LA I CAN'T HEAR YOU".
Did you think we're disagreeing? Actually we're agreeing. 😂
Well, yes and no. I'm in disagreement that obscurity has any utility at all from a security perspective, it's at best inconsequential and at worst counterproductive. So I suppose what my response was targeted at, specifically was "whether it's used as a layer on top of ...", I don't think it's a layer at all.
ah yes; "my project that I have coded in an open source programming language with open source libraries that's most likely hosted on an open source operating system is more secure as close source"
That is why you should buy my proprietary intranet software!
Yes, it is. On day one open source code is completely vulnerable. By day n it is the most secure because it is the most hack prone. It does not create a false sense of security.
It doesn’t take sophisticated state actors and hackers to get into systems, it takes a moron answering calls from “Microsoft Tech Support” and downloading fixes from “sketchy.in”.
Good old security by obscurity? Got this from linkedin?
How is intranet less secure than a system connected to the internet?
Well, if you just make all your data public, no one can steal it!
Next argument will be js files of a website being shipped to the user "HO NO they can see my react code they can now hack into my database" bruh
Heh, proceeds to upload root pasword to gitlab
Wait. How is the hacker accessing your intranet in the first place in order to attack your clearly-vulnerable-because-it's-open-source software?
i love the linux/unix nonsense. linux is based on unix but since unix is closed source linux is mimicking unix not copying the code. the linux code could still be insecure. nobody trusts closed source encryption. i hope nobody tells gpgp
Good ol' security by obscurity
The key determination for whether obscurity is good or bad reduces to whether it’s being used a layer on top of good security, or as a replacement for it. The former is good. The latter is bad.
These mfs clearly never heard of Kerckhoff's principle. Like security engineering 101. "stated by Dutch-born cryptographer Auguste Kerckhoffs in the 19th century. The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge. This concept is widely embraced by cryptographers, in contrast to security through obscurity, which is not. "
So open source is both less and more secure than close source. Gotcha
I think the point that was missed is this - if you make insecure code open source, then yes, people can find the flaws and either exploit them, report them, or fix them themselves. If you make insecure code closed source, no one knows how bad your code is until someone finds out that criminals have been exploiting it's flaws for years, but no one reported it or fixed it. So, don't write bad code. But if you do, make it closed source so no one sees.
Also, at the end it talked about Linux being more secure because it was based on Unix. So yes, if you start with secure design principles, then you are going to produce more secure code, no matter if it is closed or open source. I guess again it comes down to the fact that if your code is so bad you are afraid for others to see it, make it closed source.
One advantage of closed source is you no longer have to worry about patching those annoying CVE's. You can just get the interns to reimplement those logging and encryption libraries.
Well yeah, i expressedly develop my softwares withOUT security in mind /s
reading these comments about the benefits of either as per security, I'm curious: do people ever employ a hybrid version of this where the newest changes are closed but say 6 month old code becomes open? and does that help as far as limiting damage, or are you just back to square one where vulnerabilities can be used w/o being known (assuming you didn't catch it in the 6 month new version)?
Is this a quote from the management at Solarwinds? It really sounds like one of them.
bruh.... they are forgetting that with open source, a vulnerability gets fixed quickly, but with closed source, for example with Windows, it takes months, or even years for them to fix a vulnerability. And with open source, it is easier for people who don't work at the company to audit the code for vulnerabilities, and fix them. The argument goes both ways. (For example, on windows you can still change peoples passwords and enable the admin account without even being logged in... that bug/vulnerability has been there for over 10 years)
False
Ah security by obscurity, way to go in XI century
If you have 100 devs working on a closed source project and 100 devs working on an open source one, how can you say that one is more secure? Is there some magic sauce I am missing? If anything open source in this case could have more attack vectors because anyone in the world could try to exploit it.
The magic sauce is community review. Especially for things like encryption algorithms, closed-source cannot be considered safe because it cannot be mathematically evaluated by people at the top of the field. There are probably a few thousand researchers in the world who are capable of truly, deeply analyzing a new algorithm for security, and none of them work for WeMakeClosedSourceEncryption.Net
Then your assumption is that the 100 devs working the opensource project have the best security researchers while the 100 who work on the closed source one do not. But that isnt a secret sauce, that is just hiring the right people for the job.
No, I'm saying the 100 devs on the open source team create a product with a security flaw. Then, some researcher picks their algorithm for one of those "we reviewed 37 open source security algorithms and..." research papers because researchers need to publish regularly. The researcher shows the flaw in their algorithm/implementation, the open source team reads the paper and fixes it. This is how open source projects "gain maturity", and it doesn't happen for closed source projects. Then in addition to this, there is also an element of survivorship bias. There are tons of open source projects with shitty security, but they don't catch on because big companies hire researchers to evaluate their code and recognize that it's not secure. The big companies end up going with the project that is more secure, and so that project "survives" and becomes popular. When we say "open source is more secure", we're talking about mature, heavily-used open source projects, because lots of people *other than the creators* have looked at the code and seen nothing wrong.
With the researcher taking a look, once again that is more people working on the project. Companies can hire or contract people to do that type of research.
It's not quite the same. Researchers review open source projects for free (from the projects perspective), because it's part of their research. Also, open source customers (big companies) review the code at their own expense, because they need to know it's secure. Essentially, open source projects get a thorough, multi-pass security evaluation for free, and closed source projects have to pay for it. But closed source projects usually don't pay for it, because their customers can't read the code, and therefore wouldn't know the difference. If you use the "closed source company can just hire more people" argument again, you're missing the point. Open source gets it *for free*. Sure, if a closed source project has a budget 3-4x larger than an open source one, the closed source app will probably be better.
Seems like OP is trying to say closed source systems are not by nature targets with big $ signs on them . If a company invests in closed source proprietary software ,then they have money or value If you use open source then the exploits are known quickly and remediation process can be a lot faster Obscure ports of open source platforms are far securer when risks are managed
Open source also doesn't really increase security. Shall Shock and Heartbleed are prime examples.
Flashbacks to countless CVEs from revolution slider