How ironic. The "security through obscurity" criticism is a pure "cargo cult" phrase. It appears that many remember the phrase but few remember the context in which it actually makes sense. Obscurity is almost always a part of a security system. If not, then why don't you post your PerlMonks password in your signature? Why do you feel you must obscure it? Why do you obscure your private key? Duh.
The phrase was coined because people were making up encryption algorithms for wide-spread use with no apparent regard to any research in the field of encryption. They kept the algorithm secret in hopes of improving the security of the resulting system. So they prevented any review of their design, which is a good way to prevent the design from being improved.
Certainly, the obscurity made the already-written algorithm a bit more secure. Unfortunately, it prevented improvements that would increase the security by modifying the algorithm from being identified. So the system was made more secure in the short term but was made less secure in the long term by closing down the potential for suggestions of better algorithms.
Let me quote myself:
Also,security by obscurity is no security at all.I understand the point of that old saw, but it isn't actually true. A great deal of security is obscurity. If I were designing a new system, then I'd certainly open the design to public review rather than keep the design secret. That is quite a bit different than having a live system that has had several security problems found (and fixed) in the last few months.Opening up free access to the source could certainly increase the rate at which any remaining security problems are found. However, there wouldn't be a team looking specifically for security problems so the ones found would most likely be by people doing the looking for "bad" reasons and so we might not even get the security problems fixed if they are exploited subtley enough.
[Someone] couldn't have guessed how to munge things without access to the source. I'll take a layer of obscurity until such time as a good security review of the site has been completed.
The other problem is wasted time. If we start getting patches from random people who think they are helping but don't have a solid clue, then we just make the resource problem worse. I've personally lobbied and gotten gods added specifically to help get the good patches that you guys have already provided but us deadbeats haven't applied.
So I think the best plan for "getting help" is to continue to add people who meet the requirements of 1) trust and 2) competence to pmdev if they show an interest in contributing.
So, as new code is written for PerlMonks, it is reviewed. I often post such code in public on the site.
If the PerlMonks code was being pushed out to be used on other web sites, then I'd also be much more interested in opening up the source code for review. But even then, the source code would likely be the latest release and proposed changes to releases. It would not be the live code.
All members of pmdev can see the live code. This fact has already been used by a (former) pmdev member to "hack" the site. Luckily, the results of the hack were fairly minor.
I'm getting more and more of the code reviewed such that I'm not worried about security issues with more parts of it. But I don't think it will ever be a good idea to have public access to the live code.
Most of the code at PerlMonks has already been made public either as part of an Everything release or as part of reviewing proposed changes. The rest of it has been open to review by a large group of volunteers.
- tye
In reply to Re^5: Wat was the Architecture used in perlmonks (open?)
by tye
in thread Wat was the Architecture used in perlmonks
by kprasanna_79
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |