"The entirety of your argument is that it's a good idea to use code or protocol secrecy as a type of secret password."
You're getting close to understanding but still not there. Obfuscation is the use of secrecy in code, protocol, configuration, etc to increase knowledge or access required for an attack. What you wrote is partly there but some secrets (eg memory-safety scheme) require more than disclosure to break. Also, what I've always called Security via Diversity claims that everyone relying on a few protocols or implementations means each attack on them automatically can hit huge numbers of users. Therefore, each should be using something different in a way to cause further work or reduce odds of sharing a vulnerability. The difference can be open or obfuscated.
"All the rest is a list of non-sequiturs"
Then followed followed with claims showing that this makes mass attacks nearly impossible with targeted attacks extremely difficult and with a custom attack required per target. Even getting started on an attack practically requires they've already succeeded in others. You dismiss this as a non-sequitur, which makes no sense. I've substantiated in very specific detail how my method provides great protection vs totally-open, vanilla, standardized-for-all methods. To avoid mere security by obscurity, my methods still utilize and compose the best of openly-vetted methods following their authors' guidelines to avoid loss of security properties.
I also noted this has worked in practice per our monitoring with our systems merely crashing or raising exceptions due to significant vulnerabilities that simply didn't work. Success via obfsucation + proven methods was reported by many others including famed Grimes [1] who opposes "security by obscurity" in most writings. Despite arguing against me for decade plus, computer science has started coming around to the idea with many techs published with DARPA funding, etc under the banner "moving target" that try to make each system different with some having mathematical arguments about security they provide. Most are obfuscations at compiler, protocol, or processor level. (Sound familiar?) That field was largely result of people doing what your side said resulting in attackers with hundreds to thousands of 0-days defeating such software with ease with fire-and-forget, kit-based attacks.
So, the evidence is on my side. In practice, obfuscating other otherwise proven tech in good configurations greatly benefits security even against pro's. I gave clear arguments & examples that it makes attackers' job more difficult, requires they have inside access, and forces customized attacks instead of mass fire-and-forget kits. On other hand, your counter shows little understanding of what the field has accomplished on defensive side or the economics of malware development on their side. Plus, equates all obfuscation with custom work by the least competent on hardest parts of software. You've only supported keeping amateurs out of obfuscation decisions unless following cookbooks for easy things that are hard to screw up (eg Grimes-style obfuscations). Additionally, you follow up with a ludicrous idea that people unable to use some installers/scripts (all my approach requires) can safely compose and configure arbitrary, complex protocols that such people regularly get wrong in single-protocol deployments. What lol...
So, I guess this thread has to be over until you refute the specific claims that have held up in both theory and practice when done by pro's. Further, you might want to test your theory by switching to Windows, OpenSSL, Firefox, etc because these have had most review and "pen-tests" by malware authors. Plus, publish all your config and I.P. information online in security and black hat forums for "many eyes" checks. Should make you extra safe if your theory is correct. Mine would imply using a Linux/BDS desktop w/ strong sandboxing, non-Intel where possible, LibreSSL, and automatic transformation of client programs for memory/pointer safety. Been fine, even in pentests by Linux/BSD specialists. Windows, OpenSSL, Firefox, etc? No so much...
Good luck with your approach of open, widely attacked software in standard configuraiton that you publish online. You're going to need it. :)
> some secrets (eg memory-safety scheme) require more than disclosure to break
And to that extent it isn't actually a secret. If the secrecy is providing you with anything then it comes at the expense of having a unique design but is lost by a compromise of any device. That isn't cost effective.
Your Microsoft link has an excellent exemplification of the flaw in thinking that leads to the erroneous conclusion that obfuscation is productive:
> Renaming the Administrator account can only improve security. It certainly can't hurt it.
The trouble is that it can. Renaming the Administrator account not only breaks poorly written malware, it also breaks poorly written legitimate software. Then the system administrator has to spend time and resources fixing a manufactured problem that could have been spent on other measures that achieve a better security improvement.
And you keep talking about things like diversity and sandboxing as if you can't use these things without hiding their design, but you can. Obfuscation of design is essentially useless because it has similar costs but a worse failure mode than other ways to improve security -- including the ones you keep talking about. Or layering independent systems.
You claim this layering is "ludicrous" but can you name a single major company that doesn't separately use all of those things already? Layering, for example, IPSec and TLS is the same work as configuring them separately. Being independent from each other so that a vulnerability or misconfiguration of one doesn't defeat the other is the idea.
Every security measure comes at a cost. You may need to configure more things etc. Which is why wasting resources on high-cost low-benefit measures like protocol secrecy harms actual security.
You're getting close to understanding but still not there. Obfuscation is the use of secrecy in code, protocol, configuration, etc to increase knowledge or access required for an attack. What you wrote is partly there but some secrets (eg memory-safety scheme) require more than disclosure to break. Also, what I've always called Security via Diversity claims that everyone relying on a few protocols or implementations means each attack on them automatically can hit huge numbers of users. Therefore, each should be using something different in a way to cause further work or reduce odds of sharing a vulnerability. The difference can be open or obfuscated.
"All the rest is a list of non-sequiturs"
Then followed followed with claims showing that this makes mass attacks nearly impossible with targeted attacks extremely difficult and with a custom attack required per target. Even getting started on an attack practically requires they've already succeeded in others. You dismiss this as a non-sequitur, which makes no sense. I've substantiated in very specific detail how my method provides great protection vs totally-open, vanilla, standardized-for-all methods. To avoid mere security by obscurity, my methods still utilize and compose the best of openly-vetted methods following their authors' guidelines to avoid loss of security properties.
I also noted this has worked in practice per our monitoring with our systems merely crashing or raising exceptions due to significant vulnerabilities that simply didn't work. Success via obfsucation + proven methods was reported by many others including famed Grimes [1] who opposes "security by obscurity" in most writings. Despite arguing against me for decade plus, computer science has started coming around to the idea with many techs published with DARPA funding, etc under the banner "moving target" that try to make each system different with some having mathematical arguments about security they provide. Most are obfuscations at compiler, protocol, or processor level. (Sound familiar?) That field was largely result of people doing what your side said resulting in attackers with hundreds to thousands of 0-days defeating such software with ease with fire-and-forget, kit-based attacks.
So, the evidence is on my side. In practice, obfuscating other otherwise proven tech in good configurations greatly benefits security even against pro's. I gave clear arguments & examples that it makes attackers' job more difficult, requires they have inside access, and forces customized attacks instead of mass fire-and-forget kits. On other hand, your counter shows little understanding of what the field has accomplished on defensive side or the economics of malware development on their side. Plus, equates all obfuscation with custom work by the least competent on hardest parts of software. You've only supported keeping amateurs out of obfuscation decisions unless following cookbooks for easy things that are hard to screw up (eg Grimes-style obfuscations). Additionally, you follow up with a ludicrous idea that people unable to use some installers/scripts (all my approach requires) can safely compose and configure arbitrary, complex protocols that such people regularly get wrong in single-protocol deployments. What lol...
So, I guess this thread has to be over until you refute the specific claims that have held up in both theory and practice when done by pro's. Further, you might want to test your theory by switching to Windows, OpenSSL, Firefox, etc because these have had most review and "pen-tests" by malware authors. Plus, publish all your config and I.P. information online in security and black hat forums for "many eyes" checks. Should make you extra safe if your theory is correct. Mine would imply using a Linux/BDS desktop w/ strong sandboxing, non-Intel where possible, LibreSSL, and automatic transformation of client programs for memory/pointer safety. Been fine, even in pentests by Linux/BSD specialists. Windows, OpenSSL, Firefox, etc? No so much...
Good luck with your approach of open, widely attacked software in standard configuraiton that you publish online. You're going to need it. :)
[1] https://technet.microsoft.com/en-us/magazine/2008.06.obscuri...