Slashdot Mirror
When "Security Through Obscurity" Isn't So Bad
Erik writes "In this article, Jay Beale (Bastille Linux Project, Mandrakesoft) explains why Security Through Obscurity is actually a really good idea if you do it right. A good read for sysadmins." Agreed... a lot of really interesting points well written and entertaining. For starters you can't rely just on obscurity to keep you safe. But it doesn't hurt to obscure things sometimes just to make it tougher for your attacker.
The essential difference between obscurity and secrecy is that something which is obscure can be learned by research or figured out, while something secret can't be figured out from available data.
For example, if everyone's password was their spouse's or pet's name, that would be a kind of security through obscurity. This is obscure information to an outsider, but is vulnerable to someone who does their research. Whereas a true-random password would need to be stolen or guessed by brute force.
There isn't always a sharp line between the two, but it is a useful distinction.
Things like encryption algorithm used are almost always merely obscure (the general <i>method</i> of security is always obscure, but sometimes an exact algorithm is truly secret), while passwords are ideally secret, but often merely obscure in practice.
When does something stop being 'security through obscurity'? Depending on how you look at it, all forms of security, (or at least most of the ones employed over the internet) are based on picking access tokens that are really hard to guess.
Running a service with no authentication on a random port isn't great security, but in principle, it's the same kind of security as running on a well known port and requiring a unique access identifier and passcode. It's just harder to guess, but still fundamentally the same.
Real security would be achieved through schemes where all of the knowledge in the world won't gain you privileged access.
The answer is simple: ease of review. Obscurity is meant to put stumbling blocks in the path of those who desire to review the system, for whatever motive - be it academic curiosity, security assurance, or even to learn how to penetrate into it. The hidden web server trick described in the article, closed-source security software, and proprietary crypto are all examples of techniques that are meant to obscure and thus make review difficult.
The question of whether to obscure, then, reduces to whether you'd like the system you're building to be reviewed. There are several very bad reasons that could motivate you to hinder review of your system: attempting to hide security flaws you either know or suspect to be found therein is one of the bigger ones.
But the decision to impede review can be perfectly reasonable - depending on who the reviewers are likely to be. If you know, for instance, that your community of reviewers includes honest, skilled people who want to use your product and who will alert you to problems that they find, then that's a very big reason not to obscure anything. This is what motivates Linus, the Apache group, the GnuPG folks, and everyone else out there tirelessly trying to produce systems that function in the most security-hostile of environments. These folks have literally thousands to millions of users, almost all of whom are honest, and many of whom are skilled enough to discover flaws in the system.
Joe Sysadmin doesn't have that kind of community. His users are very likely incapable of discovering security flaws, or if they are, unlikely to share the information they find with Joe. The majority of people who might be interested in reviewing Joe's network are malicious and intent upon using any information they find to the detriment of Joe and his users.
In this case, the decision to put up walls of obscurity is as much of a no-brainer as the decision to use an open-source web server. Joe has assessed his community of potential reviewers and has determined that, on the whole, he'd rather not have that set of people learning things about his network. He will certainly use products that have proven themselves under strict review, but he is under no obligation to describe to anyone how he's configured his network. In his situation, doing so would only undermine his security.
Your claim (which contradicts the entire point of the article, which is that a little obscurity on top of a secure-as-possible system can't hurt) doesn't circumvent his argument whatsoever, and I really don't see why there is such an aversion to the idea of obscurity on here.
His point, which is very correct, is that (using the website as the example) someone has to be very "noisy" to actively seek out non-standard ports/services: If there is a hacker targeting your system (s)he will leave a lot more fingerprints and evidence of their actions doing a cascade scan through your servers/ports than if they simple waltzed in and connected to private.company.com. The point is that each additional piece of hidden information is one more hurdle for the prospective hacker to have to jump over: It's a shitload harder to hack an unknown webserver on an unknown machine through an unknown firewall than it is to hack IIS 5.0 on Windows 2000 SP 1 pre-HOTFIX XYZ running on port 80 at intranet.company.com (hint: In the first case there will be a swath of evidence attempting various tactics to determine what the OS/webserver/firewall restraints are. In the second Jimmy pulls up black hat exploit #1027-D [the one that the public doesn't know about yet] and applies it against the server. Instantly the server is ownzed and there are zero tracks because to the other systems everything looks fine. Jimmy puts in his keystroke grabber, cleans up his tracks, and disappears into the night).
The concept of enhanced security through obscurity is absolutely as clear as day. Pretend that I encrypt a piece of information to send to you: Now of course I'm going to pick a very secure algorithm so let's say that I go with Twofish. Now to the best of my knowledge it is a super secure algorithm and I'm safe and there is zero chance that it could ever be broken, but pretend that somewhere someone out there knows how to break Twofish with just a month of computer time: Do you think that they'd waste the month if they were unsure what algorithm you used? Pretend that they see an encrypted file called stuff.enc, versus bank_numbers.twofish: Which one gives them a headstart and motivates them? The standard (moronic) reply to this is "Well use a secure algorithm/software/OS/etc.!" however that is a foolish statement: Many algorithms/software/OS' have fallen in the past after years of people super-duper-assuring you that there is absolutely nothing wrong. So in other words unless you are absolutely sure yourself about every piece of software and algorithm that you use, a little obscurity can't hurt.
And from a sufficient multi-dimensional sample. Nothing else works.
Try running a different kind of Turing test. Not one where you're trying to prove how intelligent or self-aware or witty or urbane you are but just who you really are.
That test immediately requires a web of trust, that someone or something we can trust be able to vouchsafe for you, and a web of deceit, that that someone or something we can trust be able to recognize you somehow in such a way that we can all trust the process.
The current authentication schemes usually fail by having a web of deceit that's too broadly woven. The senses we have provided to our systems are ridiculously inadequate. For now.
Lets create a system which can authenticate that you are you. It has to know who you are by virtue of your having been presented to it once under trustworthy circumstances.
What you know is useless.
It should be able to authenticate your cadaver. So much for all the password schemes in the world. Period.
It should be able to identify you AS a cadaver. That means that the bio-metric data must include measurements of things like temperature, heart-beat rate, eye movement, involuntary tremors and other things which correlate to identify you as you.
Listening to a "Rich Little"-caliber mimic on one of his good days will fool the blind but the disguise is blown the moment you open your eyes. Therefore the bio-metric data must be multi-dimensional.
Listening to you say a common phrase as you stand in front of it (actually you'll be potentially surrounded by its sense organs,) it should be able to identify you from anyone else on the planet and tell not only if you're you, but if you're angry, in distress or just inebriated.
And if it doesn't recognize you, you can go suck an egg or spend a night waiting for your attorney.
Until then security is mere mental masturbation.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
I had thought obscurity went hand in hand with security. Stuff like trimming off your internal MTA's before sending things off to the internet and making sure that your firewall reveals no clues about what it's running. The more you make 'em work, the easier it is to catch 'em has always been my motto.
The truth about Scientology, Xenu, and you: Operation Clambake
Or, for that matter, for your co-workers or whoever inherits your systems. Obscurity can improve security, but at a dreadful cost: maintainability.
:)
That's what I like to call "job security."
Kind of like not commenting code. Make it impossible to interpret by anyone but yourself and you're simply increasing your value as an employee!
-- "Complacency is a far more dangerous attitude than outrage." -Naomi Littlebear
defense always has an advantage over offense, in terms of time and effort
I would argue that this is not the case in the computer world.
o A defender has many bases to protect; often with few resources.
o The human resources needed to build an effective security team are incredibly expensive.
o If an attacker compromises even one 'base', hiding tracks and stepping to other resources is often easy.
o Even detecting a compromise can be extremely difficult, let alone determining what damage has been done, etc.
o Attackers may attack at leisure and need only find ONE of many possible vulnerabilities.
o Attackers can also attack with very little cost or consequence by bouncing through different proxies.
o Defenders must obey the law, while attackers may not.
o In the real world, defenders can launch offensive measures as a defense; you can't really do this in the computer world.
o Attackers often find out about vulnerabilties in the defender's system before the defender knows about them
I don't think that defenders have any advantage; attackers almost certainly have the upper hand. In the real world, the following factors make defense positions stronger in conventional warfare:
o Defense can see that attack comming and anticipate what the attacker will do
o Attacker's goals are often obvious
o Attacker is out in the open, while defense has had time to build heavy physical defenses and stockpile resources
o Attacker is unlikely to find a gaping hole in the defender's defensive measures
o Attack is resource consuming
The reason security through obscurity doesn't work is it assumes a lesser effort provides a deterrent after a greater effort has already been spent. If the attacker can beat Kerberos authentication (or even a password challenge) the port scan becomes a trivial effort.
The one advantage of the article's example is not security related at all. Filtering script kiddies saves a potential bandwidth hit by quietly dropping port 80 traffic.
(Not the part about the comparative ease of exploiting security holes in source code vs. binary code -- the part about OS advocates somehow "always" forgetting that fact.)
In my experience, advocates of open source are highly aware that it's easier to exploit security holes in source code.
After all, to do that, one must find them first, correct?
And unless most or all of the people looking for them also intend to exploit them in an offensive way, the result will be that said holes will be fixed in a defensive mode vs. offensive attack faster than for proprietary, binary code.
Remember, defense always has an advantage over offense, in terms of time and effort -- the "battle" is on the defender's own turf. Offense can make up for this inherent disadvantage to some extent by, for instance, having the element of surprise.
For most such offensive counter-measures, having the source code is not an advantage, in fact it's a disadvantage, if the defense also has the source code.
That's because the defense can deploy fixes to holes faster than the offense can attack them, so, assuming they both find out about them at the same time, the defense wins. (This is generalizing, by the way. Specifics always vary, of course.)
Now, ask yourself this question: when it comes to binary-only code, who is likely to know more about the internal operations of the code -- the defense, in this case, law-abiding users, or the offense, willing to obtain THE SOURCE CODE through illegal channels??
That's why Open Source has such an advantage here -- the defense, collectively, is encouraged to share, generously, insights about the software, while the offense must remain fairly isolated (a general rule about law-abiders versus law-breakers; while law-breakers sometimes pool their resources, they have an uphill battle with regard to such activities compared to law-abiders, who can do their pooling in the open and/or in hiding).
When it comes to proprietary software, law-abiders are increasingly discouraged from sharing insights, info, breakages, fixes, etc., while the opportunities for pooling resources on the law-breakers' side remains pretty much the same.
But there's a special prize law-abiders are denied that law-breakers have the opportunity to exploit should they gain access to it, when it comes to proprietary software: the source code.
Once they have that -- and they will, if the software "matters" at all -- the law-abiders will be on the losing end of things.
"If source code is outlawed, only outlaws will have source code."
Practice random senselessness and act kind of beautiful.
In this slashdot article by a slashdot reader.
The reader, being a Microsoft employeee, received a mostly negative response, whereas responses to this article are getting mostly positive reviews.
Funny how much acceptance of the message is affected by who the messenger happens to be.
Welcome to obscur0S kernel version 1.0.0
..
/bin
/bin: No such file or directory
login: root
password:
> ls
Tue Jul 24 02:06:22 CEST 2001
> rm -n
.
> rm
rm:
> rm /
foo bar baz foobar
> exit
exit: Too few arguments
> quit
quit: Command not found
> ^D
> ^C
> ^]
<telnet> quit
This is a replacement signature.
-- Stanislav Shalunov
This isn't about making your targets impossible to crack. It's about making harder to crack than the guy next to you.
The slowest animal in the herd principal.
Lets say me and you both run service A, when a remote exploit is discovered. Bob the happy script kiddy gets his scanner and starts looking for said service on it's default port. On your box he finds it fine, and cracks you. On mine he doesn't see it initially. So he skips me and moves on. Say bob _really_ wanted me, he would scan all my ports and find that service, but in the meantime I see a bunch of traffic searching my network in odd places.
The slowest animal in the heard is already down, but in the few seconds I gained I realize some clever escape, and viola, I'm free. Obscurity doesn't make you uncrackable, but it gives you an edge.
It seems to me that most people pass through three stages of understanding:
- Security through obscurity is bad because everybody says it is and it sounds like it should be.
- Using obscurity to supplement security is ok as long as I have real security too. It just makes me less vulnerable to the kiddies.
- Doh! I was wrong, obscurity actually is bad for many reasons (discussed below).
It's sad to see that an expert well respected by the community has only reached level 2 in understanding this concept.Now, why is using obscurity bad? I'll give several reasons.
- Obscure security generally goes untested. This means that "real security" which was there wasn't actually as real as you thought. You end up getting bitten when it's important rather than when it's not!
- Obscure security breeds insecurity through laziness: "oh I don't have to update that right away, nobody will find it before tomorrow" which turns into next week, which turns into never getting updated.
- A secure network is one in which the attacker cannot get in even with full knowledge of the network layout. This is harder to do than using obscuration, but you end up with something that's actually secure!
- Good security depends on you understanding your setup. Networks are generally very complicated just to serve their necessary function in the local environment. Adding useless complexity by obscuring simply makes the network more difficult to understand and thereby decreases security.
- Related to the previous point: knowing your network's vulnerabilities and being able to accurately analyze any attempted attacks is essential. Obscurity makes it more difficult for the attacker, but it also makes it more difficult for the home team. If you can't track the attacker's path through your spaghetti of accumulated obscurations you can't secure the network against the next similar attack. (note all successful or partially successful attacks are generally a string of smaller attacks on subsystems, which must be strung together to get all the way in.)
- All security measures are a tradeoff between usability and security. Obscuration, on the other hand hurts usabality without actually providing any security benefits. Don't think it doesn't matter if you do something in a totally unconventional way: it creates problems for your users because things are non-standard (and may not match documentation!), it hurts your employer in terms of the others that will have to maintain the system, and it hurts the community by complicating issues unnecessarily. Spend you usability trade-offs on real security. I'm sure that will be enough if you're actually secure.
- Also, most of us aren't as ingenius as we think we are. In many cases by doing something you think is clever you're more likely to make things worse rather than better through unforseen consequences. I think the phrase is "keep it simple stupid"! Unfortunately this is especially true for people in class 2 above, who by definition haven't reached class 3, where they understand this.
I could probably go on, but I'll stop now. I think these are the most important points. It's really too bad when people without a lot of foresight get in positions of influence.Security through unpopularity. Let's face it, if you run a web server under BeOS, the likelyhood of getting hacked compared to running IIS, is roughly the same as the ratio between BeOS users and Windows users. Cheap ass security advice: find the most unpopular system you can (put those Commodore 64s to use!), lock it down to the best of your sysadmin abilities, and start praying!
Well, your fingers weave quick minarets; Speak in secret alphabets;
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
If you log in and are not authorized by Adobe, you will be in violation of DMCA statutes and join Dmitri Sklyarov in jail.
Have a nice day.
Login:
-- .sig are belong to us!
All your
A feeling of having made the same mistake before: Deja Foobar
in Applied Cryptography...
He gave the example of:
If you have a letter you don't want anybody to read, and you put it into a safe, and hide it in New York, that's not security; that obscurity. You're hoping that they (your enemies) won't find the safe.
However, if you give crackers the safe and a diagram of the lock, and they still can't figure out a way to lockpick it, then that's security.
However, hiding the safe in New York in addition to securing it doesn't hurt at all. It just takes them longer to find it.
Particularly entertaining in this article was the following:Are there really people out there who would choose not to obscure something like the name of a server because they thought it would harm their security ? You can't be serious...
Like I said.
--CTH
--
--Got Lists? | Top 95 Star Wars Line
Trolls throughout history:
Trolls throughout history:
Jonathan Swift
So a big apache expliot comes out, and a half hour later there's a patch (thanks to open source) and you apply it/ recompile. Then you look at the apache log files and don't see any unusual activity. So you're safe, right? wrong. Your system was compromised and a rootkit was installed. It cleaned up all the logs. It added a backdoor to getty. It modified your MD5 checksum verification. It modified your rpm so that it points to the hackers server, no matter what you say. It modified gcc to include a backdoor into any program that requires authenitcation and insert this code into any gcc recompiles.
Do I really need to prove that it's easier to change:
if (checkPassword(password)) {goCrazy();}
to
if (checkPassword(password) || !strcmp(password, "k00ldud3") {goCrazy();}
than it is to use a disassembler on an executable with no symbols to figure out what the hell is going on and insert a back door? Not only does this require a much higher level of expertise, it also requires significantly more time for the person who can do it.
Trolls throughout history:
Trolls throughout history:
Jonathan Swift
Furthermore, running services on non-standard ports provides no real obscurity but it makes administration substanitally harder. In this way, it is in no way good policy.
Good obscurity tactics involve hiding internal systems from your external DNS servers, trying to avoid letting people see what OS you are using, etc. Forcing people to do guesswork is good, but it should not inconvenience your users (that should be left for the more fundamental security measures.
Attackers should be forced to make their attack based on limited information. By limiting the information they have, you can limit the effectiveness of the attacks and maximize their effort. But it should not be used as a standalone strategy.
Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
LedgerSMB: Open source Accounting/ERP
Security through obscurity is usually discussed in terms of hiding encryption algorithms and security protocols, which is a totally separate issue. Read this article by Simson Garfinkel on the subject, for instance.
So to me the article seemed like a giant non sequitur.
Tim
'cause the company paid for it. What there was of it was fairly neat... How best to lock down apache, IIS, Netscape server, etc...
The bulk of the time in class, however, was spent discussing how to arrange things to make everything else obscure as possible.
We talked about things like firewall masking, where firewall software automatically stripped out the software version indentification strings out of ping and logon responses. Stuff like that.
The ethos the Verisgn teacher had was that there was only so much you could do to protect a 'celbrity' system, even if you went so far as to impliment a client-certificate setup. The best way to secure a system was to make it difficult to find as well as crack.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
There are two kinds of "Security through obscurity", and it confused some people. (Insert funny joke about clueless managers and Microsoft-heads here)
First there is the bad kind: you're a software vendor and you hope that nobody will notice that your "secure" software uses ROT-13 instead of RSA. You are protected by the DMCA anyway (remember: crack ROT-13, go to jail).
Then there is the second, good kind: if I'm an admin, there is not reason I shouldn't strip outgoing email of any headers that my reveal the structure of my internat network (some people ARE arguing that you shouldn't do that.)
I don't really like this "security through obscurity" thingie. Let's make the difference between full specs release and not telling anyone more than they should know. This is the way to built a really secure network.
Nobox: Only simple products.
Security Through Obscurity was one of the slogans thrown back at the complacent computer vendors and sysadmins. As with any slogan though the medium does not allow for a sophisticated or subtle message.
About ten years ago the UNIX comunity started to wake up to security issues. Previously the UNIX approach had been pretty rudimentary, most UNIX machines were departmental or personal workstations and security was a nice to have but relatively few people depended on it actually working.
Then the Internet grew beyond academia and suddenly security started to matter an awful lot.
At the same time traditional UNIX security nostrums started to be re-examined, like the lack of shaddow passwords. At the time the idea of protecting a password file with a password was considered by most UNIX advocates to represent the evil of security through obscurity. The UNIX one way encrypted password file was held up as the exemplar, to want to protect it was to fall foul of the sin of 'security through obscurity' and obviously anyone like myself who advocate3d the practice had to be a fool. Today anyone who doesn't use shaddow passwords is considered foolish.
What it boils down to is that slogans have a tendency to turn into dogma. Then someone comes along and points out that the real world is not as simple as the slogan.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
This was written in 1853 by Charles Tomlinson, and is only an excerpt of the the treatise, but it shows that people recognized that 'security' trough obscurity was not really security at all, way before the digital age.
...The unscrupulous have the command of much of this kind of knowledge without our aid; and there is moral and commercial justice in placing on their guard those who might possibly suffer therefrom. We employ these stray expressions concerning adulteration, debasement, roguery, and so forth, simply as a mode of illustrating a principle -- the advantage of publicity. In respect to lock-making, there can scarcely be such a thing as dishonesty of intention: the inventor produces a lock which he honestly thinks will posess such and such qualities; and he declares his belief to the world. If others differ from him in opinion concerning those qualities, it is open to them to say so; and the discussion, truthfully conducted, must lead to public advantage: the discussion stimulates curiosity, and curiosity stimulates invention. Nothing but a partial and limited view of the question could lead to the opinion that harm can result: if there be harm, it will be much more than counterbalanced by good.
A commercial, and in some respects a social, doubt has been started within the last year or two, whether or not it is right to discuss so openly the security or insecurity of locks. Many well-meaning persons suppose that the discussion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fallacy. Rogues are very keen in their profession, and already know much more than we can teach them respecting their several kinds of roguery. Rogues knew a good deal about lockpicking long before locksmiths discussed it among themselves, as they have lately done. If a lock -- let it have been made in whatever country, or by whatever maker -- is not so inviolable as it has hitherto been deemed to be, surely it is in the interest of honest persons to know this fact, because the dishonest are tolerably certain to be the first to apply the knowledge practically; and the spread of knowledge is necessary to give fair play to those who might suffer by ignorance. It cannot be too earnestly urged, that an acquintance with real facts will, in the end, be better for all parties.
Some time ago, when the reading public was alarmed at being told how London milk is adulterated, timid persons deprecated the exposure, on the plea that it would give instructions in the art of adulterating milk; a vain fear -- milkmen knew all about it before, whether they practiced it or not; and the exposure only taught purchasers the necessity of a little scrutiny and caution, leaving them to obey this necessity or not, as they pleased.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
I think the trouble is not having security through obscurity, but gaining a false sense of security thru obscutity.
It is the thinking that your server is secure and untouchable that is the problem