Security By Obscurity — a New Theory
mikejuk writes "Kerckhoffs' Principle suggests that there is no security by obscurity — but perhaps there is. A recent paper by Dusko Pavlovic suggests that security is a game of incomplete information and the more you can do to keep your opponent in the dark, the better. In addition to considering the attacker's computing power limits, he also thinks it's worth considering limits on their logic or programming capabilities (PDF). He recommends obscurity plus a little reactive security in response to an attacker probing the system. In this case, instead of having to protect against every possible attack vector, you can just defend against the attack that has been or is about to be launched."
I hate it when people always seem to take the phrase out of context and apply it to mean any kind of security, like network security or the old Windows/Linux battle. It's a completely different kind of situation, and in the former it's especially true that security by obscurity is a hardener layer. It's also why Linux has managed to stay as (consumer) malware free to day, even though it still has a fair share of its own worms and other security problems.
Obscurity only makes your security "brittle". Once broken, it is completely broken. Like hiding your house key under a flower pot.
Which means that the real security is the lock on the door. All you've done is allow another avenue of attacking it.
That's fine and all. If you want to create your security through incomplete information, or different tactics and strategy, that is a choice.
Just don't be a childish whining little bitch and run to the FBI to stop the big bad anti-social "hackers" from revealing your used-to-be incomplete information in security conventions and trying to have them arrested.
You get double whiny bitch points trying to invoke copyright to prevent the "leakage" of your incomplete information.
I certainly get the point of the article, but a system that is secured through well thought out and tested means will always trump a system where, "Golly Gee Willickers Bat Man.... I hope they don't find the secret entrance to our bat cave that is totally unprotected and unmonitored".
Camouflage is the oldest and most natural form of security on the planet.
Kerckhoff's Principle specifically applies to cryptosystems. Not only does TFA describe more of a generalized application to systems and code, but it's not really describing 'security through obscurity.' It's describing informational arbitrage, i.e., profiting (not necessarily financially) from an imbalance of knowledge on one side of a two-participant game.
The dynamic adaptive approach has its merits, particularly as it is increasingly clear that most security is only the illusion of security, maintained until it is breached. But traditional 'security through obscurity' refers to systems for which the only security measure in place is maintaining the secrecy of a protocol, algorithm, etc.
It seems to me the ideal approach is a balanced one, that embraces the UNIX philosophy: cover the 90% of most common attack vectors with proven security measures (and update practices as needed), and take a dynamic adaptive approach to the edge cases, because those are the ones most likely to breach if you've done the first 90% correctly.
To understand recursion, you must first understand recursion.
Security by Obscurity is lame. The REAL test of a good security protocol is when you publish ALL the details and the bad guys STILL can't get in. If you are merely relying on somebody, somewhere, not saying anything, you are asking for it. All the real security products that people actually trust are open source. I will never, ever, ever, ever, trust anything that is closed source. There could be a back door, and you can't argue with that. Again, and again, and again, the ONLY security algorithms worth talking about are OPEN. If you can publish your work in public and STILL be secure, THAT is security. That is quite possible, it has been done many times. If you can't do that, you are just making excuses for your lame security that relies on a secret. Look at history. Your secret will be published, and then your product will be dead.
A new kind of goatse troll in which the troll commenter hides his actions by contributing to the thread in a positive manner.
*golfclap*
Well maybe I'm wrong, but I always thought the complaints of "security by obscurity" were not that obscurity couldn't be helpful to security, but that it was a bad idea to rely on obscurity.
It seems obvious to me that the more complete the attacker's knowledge, the greater the chance of a successful attack. If an attacker knows which ports are opened, which services are running, which versions of which software are running which services, and whether critical security patches have been applied, for example, it's much easier for them to find an attack vector if there is one. You're more secure if attackers don't know that information about your systems, because it forces them to discover it. That takes additional time and effort, and they may not be able to discover that information at all.
However (and here's the point), it's not a good idea to leave your systems wide open and insecure and hope that attackers don't discover the holes in your security. It's not smart to rely on the attacker's ignorance as the chief (or only) form of protection, because a lot of times that information can be discovered. It's true that "obscurity" is a form of security, but it's a fairly weak form that doesn't hold up over time. The truth tends to out.
Goatse through obscurity?
Wow that didn't even cross my mind. So in addition to contributing to the thread positively, the goatse troll is actually relevant to the topic at hand. Absolutely amazing. A technological marvel.
As a information security professional, I've always seen the whole "security by obscurity" issue somewhat misleading. By repeating the mantra, I feel many people forgot its true meaning.
Security shouldn't RELY on obscurity. That's true. But it doesn't mean obscurity, by itself, doesn't provide security benefits.
There are many examples where this is obvious. For example, would you publish your network topography on your public website? Of course not. Even if you were convinced that its security and access control are air tight, the cost of keeping such documentation "obscure" is negligible versus its usefulness by a potential attacker.
The problem arise when obscurity is used in lieu of proper security. Unfortunately, it still happens too often. But while the presence of obscurity may be seen as suspicious by an outside party trying to evaluate the security of a system, it shouldn't be considered as evidence of its insecurity, as it sometimes is.
Finally, I understand the "many eyes" argument, and how public disclosure of the security details of a system can help improving it. After all, nobody would think about trusting a crypto algorithm that hasn't been made public and scrutinized accordingly. But this logic cannot be generalized for all systems in all context.
You're confusing the "obscurity" portion of that statement.
Passwords should rely upon the difficulty in cracking them due to their complexity. The system is known. The password is not known.
Security through obscurity refers to the workings of the system being hidden. Such as the key under the flower pot opening the door. Once that information is discovered, the system is cracked.
No, that would be "security through obscurity".
But that does nothing to improve the security of the system. If the attacker choose the correct door (or whatever) then you're left with only the defenses of that door.
No. The "security THROUGH obscurity" means that the door IS unlocked (or unlockable with the hidden key) and that the "security" comes from no one KNOWING that it is a way in. That's what the "through" part of that statement means.
I've always understood it. And you're making a very common mistake. Obscurity != Secret in "security through obscurity".
Of course, just correctly guess sooner, and then you can fix the system beforehand
One method to make such a guess is called a "code audit", and code auditing practices applied since mid-1996 are part of why OpenBSD has had only two remote vulnerabilities for over a decade.
That isn't "obscurity" in the context of "security THROUGH obscurity". The word "through" is important there.
You can have a functional security system and add misdirection to that without reducing the overall security of the system. But the system, in the end, still depends upon the original security model. Once the correct key hole is known, the lock still must be cracked.
You can add obscurity without making the security dependent upon the obscurity.
Come on, you are way off topic here. You deserve the troll remark. It's about obscurity as a risk mitigation factor, not as an unbreakable defense. That has nothing to do with what OS is better at staying secure. All "major" operating systems get code reviews. Once they get more popular, they get more people reviewing code and probing for vulnerabilities. I'm fairly certain Windows and OSX get more code reviews and probing than FreeBSD does. If you want to spend time finding a vulnerability in an OS for profit, you spend time on the one with the biggest potential gains. Getting a zeroday on FreeBSD most likely will not gain you a lot, while getting one on Windows will give you your own botnet of meeeeelions of machines, controlling meeeelions of credit cards, bank accounts and what not.
Not the quality of the code, but the obscurity of FreeBSD is what caused the lack of remote vulnerabilities.
I was promised a flying car. Where is my flying car?
Applying game theory is always an interesting approach.
However, this one misses what I consider an extremely important part: The multiplayer aspect. If obscurity is a part of your defense strategy, you can not cooperate with other defenders. As your are competing with the attacker, that means obscurity is only advantageous if the additional cost to the attacker is higher than the benefit you could gain from such cooperation. In general, your security mechanism will not be so new, innovative and hard to crack that this is true. It does depend on the size and resources of your organisation, though. If you're a large organisation that can keep a secret (say, a secret service), it could have a net advantage. For almost everyone else, though, having more eyes on the problem will generally provide a better solution than the additional difficulty that obscurity provides for the attacker.
Assorted stuff I do sometimes: Lemuria.org