I mean, it shouldn't. Humanity is perfectly capable of building secure web services without having to keep the way it works a secret. You don't publish your encryption keys with your source code, which is what your security should be depending on.
And what's more, Reddit themselves did not even use that excuse in their official statement for it, even though to me their excuse felt even less logical.
Basically, they don't want to leak the crazy features that they're developing and have such piss-poor source code management that they cannot provide tarballs of clean states of their source code.
I mean, how do they deploy new versions, if they cannot cleanly separate feature development from stable code?
When I worked there, it mostly came down two two things that leaked into every product: anti-abuse (spam mostly), and ads/tracking.
Anti-abuse is useful to keep secret because it includes tools that make spammers think they're successful. I think it's a little more nuanced than the "open source code is more secure argument", which I totally agree with - but the anti-abuse includes active mitigation measures that constantly evolve; and in this case, obscurity to how this all works is actually valuable.
A reddit-specific ad or metrics implementation isn't useful to anyone else, and it was a tough sell that the codebase should be made more complex only to accommodate configuration for a small handful of users. I know, because I made the argument that we should when I created the open-source reddit-mobile repo, which was originally broken up into plugins like the reddit python codebase. Eventually it just wasn't feasible to maintain as a 2-5 engineer team rebuilding a 10-year-old website in a couple of months. That's a story for another time.
Personally - I find it sad, and I think it got rid of one more thing that made Reddit special. Unfortunately, the only metric you can attach to this is "how much longer does it take us to ship shit", and thus, it died.
The origin of that statement (Kerckhoff's principle) refers to cryptography, not to application security.
If you take a quantitative, cost-based approach to modeling security through adversarial capability, obscurity becomes a perfectly valid security measure if it's not used in isolation. We don't use it for cryptography because the tradeoffs aren't worth it. It's better to design cryptography with provable security based on mathematically rigorous computational hardness assumptions than it is to make secret algorithms.
In the context of application security, if the decision to obscure some or all of your system incurs a non-trivial cost to an adversary, it makes sense. We can't rigorously and mathematically prove the security of applications in the same way we can prove e.g. an algorithm is sub-exponential instead of polynomial time.
You often see "security through obscurity" mentioned in the same way that people cite "appeal to authority" or "ad hominem" fallacies in internet debates. The reality is more complex than that. Fundamentally, anything that increases the effort required by an adversary to successfully compromise your system is worth considering. You just shouldn't depend on it in its entirety. Closed-source software is a good example of robust security through obscurity, as basically any security engineer will tell you (I'd rather look at source code line by line to find vulnerabilities than try to find them through trial and error in a penetration test).
No, having an open source kernel means a lot more developers looking at the code and working on a fix if some bug is found, rising the probabilities to find a bug and shortening the time required to fix it. How would keeping the source closed decrease the number of bugs?
In theory it shouldn't, but in practice people don't make perfect code that doesn't have vulnerabilities. But a lot of people would argue that by having many reviewers, you're reducing vulnerabilities. Thus, my stance is that "it depends on the situation"
Making something closed source does not make your product more secure, it only makes it harder to look at. Determined people will still try to understand how your software works in order to accomplish their goals.
To reinforce your point, see all pre-modern crypto techniques. It cannot be argued that they worked, and they were all certainly security through obscurity.
Aren't most examples things where it didn't work? The most famous case is the German "Engima" device from WWII (hardware- and 'software'-based, but cracked and readable for years before the Germans knew because they believed it was both obscure and effective) but it's wholly possible that most schemes were broken eventually. Keeping an obscure system secret is really hard, especially against a motivated attacker.
Enigma wasn't hard through obscurity. The Allies had the Enigma machine long before they were able to crack it. It was hard because with the equipment of the day, it was pretty much unbreakable in the same way that prime-number based cryptography is today. It was only A. Turing developing a completely novel kind of machine (https://en.wikipedia.org/wiki/Bombe) that enabled the decryption. In the same way that quantum computers could break the current cryptography easily. It's not obscurity, it's assuming that some (mathematical) task is hard.
Don't forget about the Polish. They too broke the encryption before, but then they were invaded, and no precision machinery was available to increase the number of rotors to 10.
https://en.m.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma
Turing did it too, independently.
I would consider the Enigma to be a very good counterexample to security by obscurity. Even after capturing a few of the apparatuses, it took a lot of mathematicians and engineers a lot of time and effort to build something that could decipher messages before the key became obsolete.
Enigma security didn't rely on security through obscurity. Having the machine didn't enable the allies to decrypt the messages. It relied on the secret of the... secret keys and the monthly key books.
It's also quite interesting to see that the Polish cryptanalists were able to reproduce the enigma machine used by the german army without even having seen one. They were able to deduce the number of rotors, the wiring, etc.
What in the end doomed the Enigma was the fact it was more a kitchen recipe than cryptography based on solid principles. It was a smart recipe for the time, but it had flaws (like the fact a letter could not be the same letter once encrypted). In some regards, most of our symetric encryption algorithms today feel a bit that way (with a lot more external scrutiny from experts however).
Even in WWII, I don't think that security through obscurity was considered as an absolute barrier. It's more in line with a "defense in depth" pattern. It gives a little more work to your adversary as he now has to figure out how your encryption works before breaking it, but it's not expected to last for long.
The Enigma was sort of on the cusp of a modern crypto technique IMO, not to say I know that much about it. I was more referring to other techniques like wrapping a message around a dowel or the Code Talkers from WW2.
The trivial counterexample is that all modern crypto techniques rely on keeping a key, or part of a key, secret. That's security through obscurity, and you've just stated bluntly that obscurity never works under any circumstances, right?
What you want to do instead is talk about tradeoffs. Talk about how much information you need to keep secret in exchange for a given window of effectiveness, and state a preference for systems which provide longer windows of effectiveness while requiring less information (such as only a key, or part of a key, instead of a key and an algorithm) to be kept secret.
Also, take care with your argument about "pre-modern crypto techniques". Some of them remained effective for centuries after being invented, which is a far cry from your "cannot be argued that they worked", and not necessarily a favorable comparison with many modern techniques, which are lucky if they make it a couple decades before being broken.
(also, of course, all cryptographic systems eventually get broken, which is why every so often we switch to new algorithms, longer keys, etc., and you seem to be arguing that any system which eventually gets broken is a system which never worked, and that's also wrong)
In context it was fair because I was responding to a situation that was already playing with the definition, and once you allow that you have to allow taking it all the way.
Unfortunately, I started my reply to the wrong comment and didn't notice until after I'd posted it and it was too late to edit/delete.
tl;dr too many people have a knee-jerk "security through obscurity!" reflex action to things they don't like, and I have a reflex action of yelling at them about it, which sometimes misfires when I don't take care to reply at the right point in the thread.
"Security by obscurity" tries to keep the way that your encryption method works obscure, it does not try to keep a specific key obscure.
For example, if your way to encrypt works like this:
1) Shift all letters along by 5.
2) Cut out every second word and put them behind the message in order.
3) Whenever there's an f, s or y in a word, double up that word and shift the second word's letters by 7.
Then if your enemy figures out how your method works, you have to come up with a completely different method.
The opposite to security by obscurity would instead once come up with a method that entirely depends on a key. You can then publicize that method (or not), and if your enemy finds out your key, you just choose a new key and you're fine again.
Open source allows for the possibility of 'many eyes making all bugs shallow', but I think the open source community assumed that was a guarantee, at least in the case of mission critical software - it's important so obviously it's being scrutinized, right?
On the other hand, with closed source, people are presumably being paid to study the code, potentially fewer but a still fixed number of eyes on the code, as it were. But then, since it's closed source, no one really knows what's going on outside the company.
Wow. Offended much? Did I say (or even imply) I had one? All I did was provide a counter to the claim that open source means more eyes which could make your software more secure.
>All I did was provide a counter to the claim that open source means more eyes which could make your software more secure.
You really didn't say much about open source and it's ability find bugs; you just cited a particularly nasty set of bugs on an open source project as a way to condemn all of open source work to being as bug-ridden as other methods.
It was more snark than it was providing a clean example as a counter-point. Someone could easily point out the millions of bugs in closed source projects as a counter to your point of equal caliber; but I think that it's clear to most of us that NO methods that we yet understand will result in bug-free code.
That violates Kerckoff's principle[0],a cornerstone of modern information security. I would run far, far away from anyone coughtelegramcough who claims "its secure, don't worry about it" and otherwise refuses to expose their codebase to scrutiny.
That's just shitty hardcode, sane human beings build only prototypes like that, not production code. Going opensource would have that code reviewed and fixed -> means positive impact on security.
And what's more, Reddit themselves did not even use that excuse in their official statement for it, even though to me their excuse felt even less logical.
Basically, they don't want to leak the crazy features that they're developing and have such piss-poor source code management that they cannot provide tarballs of clean states of their source code.
I mean, how do they deploy new versions, if they cannot cleanly separate feature development from stable code?
https://www.reddit.com/r/changelog/comments/6xfyfg/an_update...