Security Through Obscurity

Security through obscurity is the principle of protecting things by hiding them. In day-to-day life, people use it all the time. Lock yourself out a lot? Hide a key somewhere. Going to leave a valuable object in your car? Put it out of sight. Want to finish off those cookies yourself? Hide them behind the canned peas. In all of these cases, there's no serious protection; anybody who can find the key, bothers to break your car window, or looks behind the canned peas immediately gets the goodies. But as long as you don't do anything else stupid (hide the key where everyone else does, leave the car unlocked, let somebody see you reaching behind the canned peas), you get a perfectly acceptable level of protection.

In computer terms, all of the following are examples of security through obscurity:

In general, when people discuss security through obscurity, they do so with contempt. "It's just security through obscurity", they say, or "Why won't you tell me how it works? Everybody knows security through obscurity is bad". In fact, obscurity is a perfectly valid security tactic; it's just not a very strong one. You may notice that in all our noncomputer examples, it was used either in conjunction with much stronger security measures (a locked house, a locked car) or for unimportant risks (it's not really that important if somebody else eats your cookies).

Security through obscurity is bad when:

For instance, making a machine Internet accessible, not securing it, and hoping nobody notices because you aren't advertising it isn't security through obscurity. It's complete insecurity through almost no obscurity. You're protecting something important with absolutely nothing but obscurity, and the obscurity isn't very good. Not advertising something is not the same as hiding it. This is like protecting yourself from being locked out by locking the front door but leaving the back door open, figuring that nobody will bother to go around and check it.

An encryption algorithm that hasn't been evaluated by experts because it's secret isn't security through obscurity, either; it's arrogance on the part of the algorithm's inventor. Once again, there's not a whole lot of obscurity in most cases. If you get the algorithm as software, it's easy enough to figure out exactly how it works. (Building it into supposedly tamper-proof hardware helps, but it won't keep attackers out forever.) People will attack encryption algorithms; they will figure out how they work; and if the algorithms are insecure, they will break them. It's better to have experts do it before you actually start using the algorithm.

Running a server on a different port actually does provide some level of obscurity, but it's tiny. An attacker has lots of ways of figuring out what port the server is on, including checking all the ports to see what answers, asking somebody at your site how to configure a machine to talk to you, and watching the traffic that's coming to your site. Meanwhile, you pay a high price in other annoyances, as normal clients can't talk to you without reconfiguration and other people's firewall rules won't allow connections to you.

All of these frequent misuses of security through obscurity shouldn't prevent you from making appropriate use of the concept. You don't need to tell people what kind of firewall you're using and exactly how you configure it. The less information that attackers have, the better. Ignorance won't keep them out, but it may slow them down. The slower they are, the better off you are. Anything that makes it take longer to get into your site increases the chances that the attacker will go away and look for some place easier to break into, that you'll notice the attack and take steps to get rid of them, and that you'll have changed your defenses before the attacker succeeds in compromising them.

You don't want attackers to know:

You can't keep all of this information hidden, but the less of it that gets out, the more work an attacker needs to do. Eventually, an attacker can figure out where your weaknesses are, but there's no need to make it easy.