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.
Of course obscurity brings extra security. If you for example leave a note on your desk with the password written down you get some extra security by obscuring it.
The expression that "obscurity isn't security" comes from the idea that relying on only obscurity for security is a bad design choice.
Ideally you do both. First you encrypt your information for security. Then you do not onöy hide your key but also what encryption algorithm you used for obscurity.
Obscurity will not protect you from the people who knows what they are doing bit it might protect you from the script kiddies and that is a lot better than nothing.
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.
Once you're no longer obscured, you're done.
I want to delete my account but Slashdot doesn't allow it.
Call it luck, or educated guess, call it fate for all I care. One miss, and you're screwed.
link is goatse, just warning you all
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?
...but not one which is effective enough to be your sole strategy. Obscurity should be your fall back and first defence, but between these points you should have the best defence you can muster.
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).
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.
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.
ARE what AMAZON uses basically: Does ANYONE know what or how their overall schema & OS they use are?
I don't & last I knew of/checked on, it was some proprietary thing I'd never heard of, OR I could NOT get an answer!
(Which struck me as odd actually, could be totally their "own" but I doubt it actually - why rebuild the wheel in other words, but - when you have billions? Then again... why not!)
"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." - Posted by Soulskill on Saturday October 01, @06:12PM
from the can-we-try-this-at-airports dept.
Anyhow - that seemed more like security by obscurity to me actually, ala this report -> http://uptime.netcraft.com/up/graph?site=amazon.com
AND, heck, like Microsoft?? You can't even DDoS them... that's right - ever wondered WHY you don't hear that MS or AMAZON get DDoS'd? They can't be is why.
How/Why? Well - They've "overbuilt" their network capacity hugely, & to SUCH an extent, you're not going to "overload" or "saturate" connections to them, and IF you try?
"plus a little reactive security in response to an attacker probing the system." - Posted by Soulskill on Saturday October 01, @06:12PM
from the can-we-try-this-at-airports dept.
Heh - "Yes Kids" - They take proactive & reactive measures, in that they monitor for it, & close such connections past a certain point/threshold...
(The unroutable types that DDoS use, think 10.x.x.x for example, that do NOT go "outbound online" to the public net (which also used to make the IP Stack go nuts & thus, the CPU too, until most OS' patched for it))...
Then, the IP stack (MS example here) also has settings of:
SynAttackProtect, EnableDynamicBacklog, MaximumDynamicBacklog, MinimumDynamicBacklog, TcpMaxHalfOpen, TcpMaxHalfOpenRetried
Those of you that have MS' based OS can do the same via those IP stack settings, mind you, & those ALL work IN COMBINATION with one another @ THE OPERATING SYSTEM'S IP STACK LEVEL to stave off DDoS/DoS attacks too!
(Of course, in combination with hardware measures noted above both MS & Amazon do, to stall off "the unstoppable attack method" (the DoS/DDoS)).
APK
P.S.=> It's the "how & why" you NEVER see Amazon OR Microsoft getting news that "anonymous/lulzsec" (& the like) "took down MS/Amazon via DoS/DDoS"... both companies use some "security-by-obscurity" (MS in closed source code for the MOST part to most folks), & also precautionary settings as well as unknowns (AMAZON'S OS TYPE USED, from above).
(Because you KNOW that'd be "big news" IF either went down to a DDoS/DoS, of course... & especially around here with all the "Pro-*NIX" sentiment regarding Microsoft (from the sockpuppet FUD spreading trolls that keep 100 user accounts to attempt to fool others with that bullshit is more like the real truth of it though - using "jump on the bandwagon" puny marketing ploys @ psychological manipulation of the weak-minded who don't check into things themselves))... apk
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.
I think use camouflage must understand the hidden level of sophistication - machines are excellent augmenters of 'stone-turning' . Compartmentalisation of programs would be useful - from other existing programs, and of course from the system itself. But flexibility in the upgrading system and user interaction make the shared software environment a bit like cooking - proper procedures will always work, barring untidiness or the completely unexpected.
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".
This being a leftists' web site, figures that just regurgitating PC platitudes passes for "contributing to the thread in a positive manner."
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".
I was able to view it without a set-top-box. As a matter of fact, it was wide open.
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.
I always thought that the main problem in the start of high internet transmission and multiple ports was that the technology was under-utilised, with consumer e-commerce still nascent and the hackable potential not appreciated or considered worthwhile. Its becoming a public space with a depth lent by the technology, so you get people exploring all aspects and being territorial where aquisition without consequence (both money and hijacked PCs) is possible. I suppose just as a computer hacker possesion a part or all of a PC when they manage to infect it with a virus (until removed), so a grafitti scribbler owns the advertising space of public spaces they have written on until someone can remove the paint.
The more obscure a system is the harder it is to crack. Take gravity for instance; We know gravity exists, we can feel and see its presence everywhere, but due to it's obscurity, our understanding of it is quite limited. Through peeking and poking can we truly begin to understand systems, and this tends to take time, allot of time on the most obscure of systems. Besides, in all the white-noise, you have to know a system even exists to begin any sort of probing... Your attack vector may be way off is all I am saying.
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's how Apple has survived all these years...
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 read the paper and I think hes reasoning is flawed from started, he is assuming that by achieving obscurity he is effectively removing the information from the playfield while what he is only doing is to hide it. Removing it will make the information more incomplete and therefore much harder to be attacked, while by hiding it does not make the information less complete, just harder to piece together which might be harder but not on the same degree as the absolute removal (which will be secrecy). I would say even more,
The Nature can't be wrong.
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.
I have an ADT system at my home. There is a sign in my yard alerting would be burglars that my house has been secured with an ADT system. This in the non obscure portion of my security sytem. A professional thief may have studied the adt system and figured out how to bypass the security. However what he doesnt know is I have trap doors over pits that I hand dug and outfitted with sharpened wooden stakes, and unless he knows to the secret button behind the door bell to disable it DOWN HE GOES! that is the obscure part of my security system (or at least it was.. DAMMIT.. now I have to install an anvil to drop from the roof)
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.
The only thing that should be obscure are Kerckhoff and Pavlovic for totally obvious "principles".
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've always thought the phrase "obscurity is not security" was the mindless drivel of some brainwashed security product fan-boy. security IS obscurity.
obscure (definition)
1 not clearly seen or easily distinguished : faint
2 not readily understood or clearly expressed; also : mysterious
3 relatively unknown
1. password - it's only good if no one knows it or is hard to guess...OBSCURITY (definition #3)
2. encryption - the data is OBSCURED by some algorithm (definition #1 and #2)
It is employing the new method of security through revulsion.
All computer security relies on something being hidden/obscure. In the best systems, it is only the key that remains hidden...
A general purpose defence is to slow the attacker down and Iptables new connection Rate Limiting is excellent for that.
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
Peer review and public disclosure tend to keep most vendors honest, so yes the hacker gets to see the detail, but so do you when deciding what to purchase, and so do the other white-hats reviwing a vendors products and processes.
I think vendors would prefer this approach, all their faults hidden from view, and all you get to see is marketting spin.
Security is a little like Safety, even if there are problems, the exact risk is always hard to quantify, generally the systems still all seems to work fine. So its easy, particularly if it is going to cost money, to defer a fix or do nothing, and downplay the risk.
However, at times when/if it does break, the consequences can be extreme (HB Garry Federal is a nice example).
Cheers - Mark
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
"...He recommends obscurity plus a little reactive security in response to an attacker probing the system...."
I am an IT Security specialist with 30 years in the field, which puts me up with the seniors in my profession, and I have been recommending this approach for the past 10 years.
However, I have not been talking about it in conferences or publications, because to do so would rather defeat the point of the 'obscurity' part of the defence.....
One of the problems is people conflating "information hiding" and "security through obscurity".
Information hiding is the concept of not releasing information to an attacker that could help him to breach the system. So, a secret password is information hiding.
Security through obscurity is when one relies on too many pieces of information remaining hidden, particularly information that the attacker can work out.
So, a webserver that returns 404 to someone without credentials, as opposed to 403, is a form of information hiding: by not releasing information to the attacker that a resource exists at that URL. However, if the web server relies on the attacker not appending /foo to each URI, which activates "admin mode", then it becomes security through obscurity. The system relies on the attacker not attempting to append /foo to a URI, lest it open itself up to attack.
It's a contrived example, but I hope it demonstrates that, to some extent, it's a scale. The easier the information is for an attacker to work out, the more the system is relying on security through obscurity than using effective information hiding.
In summary: a system shouldn't needlessly offer information to an attacker, but there should be a minimal set of difficult to obtain information that could allow an attacker to access the system.
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.
While security by obscurity does work marginally and individually, it simply does not scale. Secure open crypto systems scale much better. Why ? because the more they grow, the more scrutiny and improvement they get. Secure by obscurity do not scale. Why ? because the more they grow, the more potential they have for attacks, and they don't get proportionally more scrutiny by security experts, researchers, developers.
aaaaaaa
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).
The author should have referenced previous work on reactive security, namely on automatic reactive security. For instance:
Highly Available Intrusion-Tolerant Services with Proactive-Reactive Recovery
Paulo Sousa, Alysson Bessani, Miguel Correia, Nuno Ferreira Neves, Paulo Veríssimo
IEEE Transactions on Parallel and Distributed Systems, vol. 21, no. 4, pp. 452-465, Apr. 2010.
Google it to get the PDF.
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
Security by obscurity works fine - you just have to chose the right algorithm and key length. What's more of a problem is ignorance of the intention of progamming activity, which can only be overcome by some formalisation, compartmentalisation and forcing programs from outside to act like bound entities that have certain rights, yet must follow operational guidelines, this way you can judge their proposed function by their size and library calls. I can see that hacking is often a prviliedge in the coding world, where you often get to try out high-level commands that mess things up after reading more progressive books on the OS/hardware owned. Where everyone shares the same space, the programs must be confined to resources necessary for their roles, just as the power of an individual in society is minimised according to their job, status (and I suppose earnings), the limiting of code used in programs making them much easier to 'x-ray' for intent.
In fact, going along the route of object-orientation, one of the benefits of object-based programming is that it is possible to create environmental rules that prevent 'bad' program objects from being instigated that don't serve the purpose of the overall environment.
"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.
The gross part of this discussion is about childish interpretations of the word 'obscurity'. If you need that to win it for 'security through obscurity' go ahead, nobody who knows what they are talking about will agree with it anyway.