Security Through Obscurity--Boon Or Bane?

Obscurity, according to The American Heritage Dictionary of the English Language, Fourth Edition, is: "The quality or condition of being unknown."

In my information security education, training, and research, I came time and time again upon the axiom that "security through obscurity is not [security]." I disagree, and I assert that I can prove that this axiom is fallacious. Sometimes, security through obscurity is appropriate, useful, and definitely secure. The axiom's assertion is that what is obscured is only hidden, and that once it's found and exposed, it is no longer secure. Well, if hiding something was the only way we were protecting it, then I might agree. But of course, it's probably not the only way we're protecting our assets. And as you will see, hiding data--making it obscure--is very common. We obscure data every day, with encryption.

Ciphers by definition hide data. They obscure data. (They can also protect the integrity of data, depending on the cipher type and implementation, but that's a topic for another article.) I've never had someone assert that we shouldn't use encryption, because it was only "security through obscurity." An encrypted application session hides the actions, functions, the data exchanged, and can even hide the actors themselves.

What's going on can be quite obscure--unclear, difficult to understand--if you cannot decrypt the communication. So if we accept that encryption is a valid form of security, and that encryption is a means of obscurity, then the axiom "security thorugh obscurity is not security" is false.

For one corporate client's project, we used stunnel to encrypt all TCP communications between remote servers and between clients & servers. There was no unencrypted TCP traffic in transit, so sniffing would have been useless to a hacker. The TCP server ports used were non-standard, high ports, not the ports normally used for those services. If a hacker did a port scan of a server, the only low port found would have been for ssh. Other open ports were "high ports", above 1024. Connection attempts to any of those ports without SSL negotiation would fail, so the application protocol in use would not be apparent during a port scan. Now that's a very obscure configuration!

A hacker can't tell which services are running, either by ordinary port scanning, examining their own non-SSL connection attempts, or even by sniffing. This sort of configuration won't work for web servers, e-mail servers, or other public servers, of course. In this case it worked well because the servers were for specific high-value services, and were better protected by eliminating the option of even casual examination by employees. I hope you'll agree that in this case the systems and business information were well protected by security through obscurity.

Obscurity is in some cases, not that helpful. Many techniques for obscurity don't accomplish much, or only make things more difficult for administration or intended users. For example, I debated for years with peers about disabling ICMP Ping responses. My assertion was & is that servers and services are easily discovered without pings. Furthermore, while some data usable by hackers can be discovered by ICMP responses, (such as OS type, network topology, etc.) the advantage of a near instant means of verifying a host response for administration and support outweighs the little information that might be gained by an attacker. Firewalls acting as ICMP proxies, port mapping, and NAT at the network perimeter all make ping filtering, in my opinion, a waste of time. Modern firewalls and security appliances can limit the rate of ping and other ICMP traffic to prevent "ping flooding", so that excuse for filtering isn't strong either.

Well, I have proved the axiom "security through obscurity is not [security]" false. And, we've seen advantages of obscurity in real-world a real-world implementation. In my opinion, and now hopefully yours as well, we can conclude that security through obscurity is in fact a boon, and not a bane.