Security Through Obscurity

With all of this text on how to keep an application’s source code and algorithms hidden so that attackers can’t view them, it may sound as if I’m advocating security through obscurity, or a defense based solely on the ability to hide the inner workings of the system. This is most definitely not the case; security through obscurity is a poor defense strategy that’s doomed to failure.

That being said, I want you to build your applications securely, but there’s no need to advertise potential vulnerabilities. To put it another way: security through obscurity is insufficient; but security and obscurity can be a good thing. If you look closely at all of the security principles and defense strategies we’ve discussed (and will discuss) in this chapter, you’ll see that they are about improving both aspects.

Security expert Jay Beale, currently Managing Partner, CFO, and Chairman of InGuardians Inc, explores this same topic (and comes to the same conclusion) in his paper “‘Security Through Obscurity’ Ain’t What They Think It Is.” Jay states that obscurity isn’t always bad, it’s just bad when it’s your only defense. He goes on to give an example: Suppose you have a web application serving sensitive internal company data. If your entire defense of this application consists of hiding it by running it on a nonstandard port (maybe port 8000 instead of 80), then you’re going to get hacked. Someone will run a port scanner against this server, find the application, and steal all your confidential data. But assuming you do take proper steps to secure the site, locking it down with strong authentication and SSL, then running it on a nonstandard port certainly wouldn’t hurt anything and might raise the bar a little bit.