Slashdot Mirror
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.
Obscurity is good when backed up by good code where it takes time and effort to break into. That is not often the case where instead obscurity is used to hide the large holes cause by badly written code. Obscurity buys you nothing when these holes can be broken into through blind attacks. And it is often for this reason why we don't like obscurity as it also motivates companies not to fix these holes as it cost time and money to look for them continuously (which they have to spend themselves if they want obscurity).
So in actuality, open code is the best compromise in general.
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.
Call it luck, or educated guess, call it fate for all I care. One miss, and you're screwed.
Does the attacker have to get through 50 doors to get the gold? Not all locked with the same key? (etc) This is good security (unless locked with the same key and so forth). ..or.. ..or..
Does the attacker have to get through ONE door that is NOT locked (the security depends upon the attacker not getting the right door) ?
Does the attacker just have to check the doors for recent fingerprints to guess which door to attack?
I thought it was obvious.
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.
Past performance IS a proper indication of how the future will be, if everything stays as expected. But reality is rarely fully what we expect it to be.
Defending against known threats is certainly part of the task of securing something - but the other part is observing what makes up the thing you're defending, and looking for weaknesses, and from that how to react when those weaknesses are exploited. Not doing the last bits is one of the very bad parts of groupthink, complacency.
One of the best ways to develop groupthink? Pretend that everything you're doing is a crucial secret, and cut yourself off the entire outside world - and thus never invite outside input to help you adapt to anything new.
Obscurity works by default - because it's all about protecting your precious secret from any experimentation. But once it becomes important to someone to test your secret, your obscurity is a very limited defense.
Ryan Fenton
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.
Just as in my house key example. The attacker has to know WHICH flower pot has the house key.
The problem is that once that piece of information is uncovered, the entire security implementation is broken.
Yes, I understand the concept. I just don't agree with it. Again with the house key example: the work of putting a decent lock on the door is negated by having an easier, alternative avenue of attacking the door.
My point is that it is not because all it does is allow another, easier, avenue of attack.
If it does not, then it is not "security through obscurity".
On top of that, he was logged in while an AC pointed out it's goatse.
(+1, Disagree)
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.
can be unmade by another man
it's that simple
the rest is just an arms race to keep one slight step ahead in constant effort and constant motion
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
The entire concept of security by obscurity acts as a justification for keeping secrets. It often sweeps up information whose release will help users much more than it will help attackers. Once it becomes a sanctioned tool of security, instead of an objective of the security, those who set up and maintain the security lean on obscurity like a crutch.
I realize my argument is an appeal to the slippery slope, but I see it everywhere in society. People, organizations, and governments can get into frames of mind wherein they lose focus of the overall goal of information security and just start obscuring everything, which makes their interactions with others difficult and sometimes hostile.
In fairness, the article itself says as much:
But inevitably, this kind of caveat is thoroughly ignored by most people. They will only hear something like "Security by Obscurity Now Considered Useful", and a whole new set of administrative roadblocks will be thrown up in the name of security, when in fact it's helping very little, if any; furthermore, those who try to circumvent the new measures to do something they consider to be within the permitted use of the network may be considered security risks (or even malicious entities outright) and will be dealt with as such, when nothing of the sort was intended.
Security thru absurdity is just crazy enough to work.
rewriting history since 2109
In information security, secrecy does not equal obscurity.
Obscurity is if I give out access cards for the doors of my building, but all the magic of the card is a single magnet, and just changing the magnetic field at the reader will unlock the door.
Another example of obscurity: I give out access cards but encode them all to the same code and just tell people this one is only for these particular non restricted zones (this is more like DRM systems).
Nope. Similar to the use of "theory" in science. The common usage of the word is not the exact same as the usage in this context.
The system is designed so that it can only be opened by the correct secret (the key in this case). That does not mean that the key is "obscure" even though it is the "secret".
Obscurity refers to the system. The key is still the secret. What the obscurity is is the fact that you're hiding (obscuring) the secret under a flower pot.
To put it another way, using a password cracker to "find" a password and spending 2^128 years doing so is very different from "finding" a password hidden under a keyboard.
People, many of your implementation examples aren't "either/or" situations. From a practical standpoint you are usually better with a layer of each: security and obscurity, For example, a strong vault that is hidden is better than the same one exposed. A steganographically-encrypted file is safer than that same file in the public domain. How much safer is open for debate, but you are probably safer with both layers in most individual *implementation* situations.
Where the debate comes alive is in two main areas:
1) Design. An open system design tends to be more trustworthy for reasons explained elsewhere. Obscurity in the *design* of any particular layer is usually bad idea (but obscurity in the choice of layers may be a good thing, e.g. what vault you chose or which tested open source encryption algorithm you picked).
2) Testing. If many people use the same system it becomes obvious if a vulnerability is found, and more people are looking for cracks. That same system in a one-off implementation is less obviously secure, even though (paradoxically) it may have been made more secure through obscurity.
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".
In the end, it all comes down to time.
If it takes you 20,000 years to crack my password with a password cracker, then the system is secure for 20,000 years. After which it is cracked (until I change my password again).
If the password is hidden on a post-it under my keyboard, then there is an easier, alternative avenue of attack. And the system is cracked in a minute.
So, having the "security through obscurity" resulted in a less secure system that was cracked a lot quicker than the original system.
That is why you do not use "security through obscurity".
What about true obscurity. What kind of OS or software runs on the computers in a nuclear missile silo? Do those computers even use an OS? The point is, with little or nothing published, an attacker who was able to access systems like those would have little realistic hope of hacking them. There's no 0 day lists, no marketplace to pick up working cracks, no books describing how the internals of such a system.
Seriously?
Contrary to the popular belief, there indeed is no God.
You may view it as "absurd" but it having no value is the whole point.
In these SPECIFIC instances, obscurity only REDUCES the security of a system.
The problem is that we're discussing computer security. Physical security is a different matter and has very limited usefulness as an analogy.
No. You misunderstood that. The "obscure" part is where you do NOT tell everyone that the key is under the flower pot.
The key is the "secret". Just like a password is a "secret".
No matter how good the lock is, once the "obscure" part is found, the security is cracked.
It may SOUND "absurd" but there are a LOT of people arguing for exactly that in this thread.
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.
No. It's the usage of the terms in the context.
The same as people complain about evolution being "just a theory". The words have multiple definitions and using the incorrect one in this context is incorrect.
That's an awful lot of effort to go through (and easily confused) just to use "obscure" in both instances.
I'll stick to "secret" to identify the password. It's in common usage in this discussion.
It seems that you're arguing over whether the word "secret" or "obscure" can be applied to a password.
Which then confused the concept of "security through obscurity".
That's why I originally used the example of a house key hidden under a flower pot.
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.
I think on a practical level, people have always implemented security through obscurity, but no one has mentioned it because... well you know.
And I'm not security expert, but the wikipedia says that Kerckhoffs' Principle merely states that the encryption key has to be strong enough (or obscure enough) that if everything else is known about the encryption scheme it should still be difficult to crack.
Frankly, Kerckhoff's Prinicple sounds like it is just a truism. A good encryption is very important. That doesn't exactly mean that hiding other information isn't helpful. I mean who advertises their ports, the names of their servers, db schema, etc.?
Democracy Now! - your daily, uncensored, corporate-free
I'll be honest, didn't even bother reading the article based on the summary. Most threats come from the inside, from people that understand the system. Obscurity isn't an issue for these people, since they built the systems. Obscurity isn't security at all.
This isn't a serious paper; it's an attempt to get vaguely pornographic diagrams into a computing journal. Since it's on arxiv, I assume it hasn't yet succeeded.
There is something to be said about the effectiveness of this tactic, but me thinks it's usually not completely intentional. I'm confident most of you know what I'm saying.
Thats the point. A secret key (this is the obscurity part) that you'd never guess or be able to figure out. Of course, practically, this is never going to be true, you'll figure it out eventually, unless the key happens to be the universe itself, in which case the rules of our universe probably aren't applicable to you. The point is that you can't do anything other than use the key though.
All the security depends on the obscurity of the key. The algorithm just makes it so the key is required, or thats the hope. Its the part that makes the obscurity work.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
What's the driving need to oversimplify this? The meme exists to put a damper on tree-fort chortle from idiots who've never performed a base 2 logarithm.
If I'm just one guy, and I grab the source code for OpenSSL and hack myself a unique protocol by adding some kind of fairly simple input permutation to AES, I certainly haven't made AES stronger, but I have most certainly inconvenienced any agency that thinks it knows what an orthodox AES bit stream looks like. There are stupid ways to do this (re-using key bits from the AES pass could blow AES open). And there are less stupid ways to do this.
One problem with obscurity is that it's a bad idea to go around asking for advice concerning whether you landed on "less stupid". And no, it's not as hard as crypto experts pretend. It's not like it's the virgin birth to mangle some bits. Experts always exaggerate their fiefdoms. What is tremendously difficult is to achieve sufficient mixing of the right potency with the minimal number of rounds--and to have any kind of formal justification for the cake-batter which ensues.
There's simply not enough expertise out there to go around cracking all the different cipher variations if every geek rolled up their obscurity sleeves (and added to strong primitives already in place), even supposing most of them make a botch of it.
The big problem with obscurity there is that you never really know if you're on the botch list. Doesn't come with a satisfaction guarantee you can take to the bank.
Finally, obscurity sucks if there's anyone on the inside you distrust by the least amount. Your fly could be undone in the worst possible way and you would have no clue.
Even in professional systems, the password is protected through obscurity, but it's been boiled down to absolutely the least amount of obscurity necessary to get on with business, so internal vigilance can be extremely intense.
How many firms hire consultants to set the master password? Maybe we should call this "security by short and curlies". They can hand over your weakness any day of the week to any black hat anywhere on the globe, but if you catch them at it, you can sue them to dirt.
By hiring a security consultant, all you've done is open up another avenue for your credentials to leak.
Come on, there are limits to this kind of cognitive reduction.
It isn't Security Through Obscurity. When Obscurity is added as part of an overall Security Architecture it is Security In Depth. For Obscurity to be a proper security enhancer, you have to have a fundamentally secure foundation onto which you add Obscurity to outside attackers. For example, I would wager it'd be very difficult to even begin to conduct cryptoanalysis aagainst an unpublished/undocumented NSA designed crypto-system over trying to crypto-analyze a documented crypto-system. I am presuming that the system itself is secure by design, as it was designed by the NSA (the largest single employer of mathematicians in the world, devoted to cryptography to boot.) So, if we are going to discuss adding depth to secure systems by overlaying more obscurity could we stop rehashing how obscurity isn't security. Anyone who knows anything about this topic knows that, Obscurity by itself does not provide a robustly secure system, it fails once the obscurity is peirced.
I came into a position a while back where my predecessor had run everything ass-backwards. He'd roll out a 'standard' FreeBSD install he built onto all the hardware which consisted of software he'd compiled years prior. He ran SSH on non-standard ports. He didn't believe in DNS (or hardware RAID, for that matter, believing in the obscurity of geom). For just a couple racks of equipment (two) there were over 15 VLANs. He didn't label anything, and documentation was worse.
When I started, the software he was installing on new hardware was over 3 years old. Some of it had vulnerabilities. But it mostly had no public face, and when it did, it was obscure (eg. SSH on a non-standard port) or it was facing something that wasn't of much of a threat (eg. LAN workstations). SSH never got exploited (that I could tell), and password cracking attempts against the machines were very rare.
Furthermore, this guy was seen as somewhat of a messiah because he could do "hard things quickly". Sure, it's impressive to do a build ina couple minutes, I suppose. But it was obscure due to being cloistered knowledge. It gave him a hell of a lot of job security, too.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
I obviously don't trust crackers, but hey... why should I trust security companies? One only can trust source code. And this means that a security company that feels itself safe for obscurity cannot be trusted at all.
Nerdy news for your nerdy needs? http://www.soylentnews.org Soylent News is people!
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
I thought that was Road Runner.
At least, when I was a kid it was always Road Runner letting poor old self-deluding Wyle E. Coyote beat himself up.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
'twould be nice if they'd just get really, really, obscure.
Laws are like sausages. It's better not to see them being made. - Otto von Bismarck
Kerckhoff's principle doesn't say that there is no security by obscurity, but that a system is only reliably secure if that security holds even without obscurity. Of course there is a game of incomplete information, and this includes information about the system itself.
Making the system public and placing all crucial information into a key is simply a matter of sanitizing and simplifying secrecy. Instead of the secret information being spread in lots of pieces that are available to different parts of the system, and can't be readily replaced if they are compromised, the entire secret is in a single block of random bits, which is only stored where it is needed, and which can be replaced when necessary.
If on top of that method information about the system is also protected, this may well yield some additional security - what Kerkhoff's principle says is that you can't rely on it.
The article pushes blatant misinformation. Kerckhoff said that a cryptosystem should be secure even if everything about the system, except the key, is known by the enemy. ("Il faut qu'il n'exige pas le secret, et qu'il puisse sans inconvénient tomber entre les mains de l'ennemi" )
Relying on obscurity for your security is poor engineering, in particular for a mass market system. Taking advantage of obscurity for "one of a kind" systems to gain an additional security advantage is fair game.
There's nothing new here, this has been done for decades and centuries. Problems arise when people think this is the golden ticket to keeping the barbarian hordes outside the castle wall.
-- Fortes Fortuna Adjuvat --
Security is all about having various layers and I think that obscurity is an important one. The lack of information can make it very difficult for a hacker to get past what he does not know or he may not even know that you exist in the first place. For example, if you don't broadcast SSID of your wi-fi, a hacker would certainly pick up some other wi-fi to hack unless he has a strong motivation to hack your wi-fi only.
"Applied security by obscurity" is not a new concept: it is usually referred to as "operational security (OPSEC)," at least in military circles. The author's use of complex notation doesn't change anything, although he seems to imply that it might be appropriate to deliberately analyze and model OPSEC at very high levels of design. The "know your enemy" concept is popular among pundits, but also problematic: while directed profit-motivated attacks and state-sponsored hacking have become popular topics in the press, there are still plenty of work-in-the-dark-do-what-we-can basement hackers out there, who will take delight in breaching your OPSEC just to prove it's possible (the ability to sell their results only adds motivation).
knows this. Any one who sells themselves as an security experts and says there is no security through obscurity should be fired, immediately.
As always its about layers and time paired against risk and value.
The Kruger Dunning explains most post on
"Be extremely subtle, even to the point of formlessness. Be extremely mysterious, even to the point of soundlessness. Thereby you can be the director of the opponent's fate." Or "all war is deception"
One of the security aspects of Multics was the limit on available programming languages. This was carried into Prime Minicomputer's Primos which restricted normal programming to PL/1 and Cobol. If you can't directly access memory, you can't hack the OS.