Thoughts on "Security Through Obscurity"
Derek Kuhnert Jul 11
Today I felt like sharing my opinion on the somewhat-contentious issue of "security through obscurity", or the practice of hiding application or system inner workings to reduce the viability of security threats. Examples include:
Having your user table in your SQL backend called "ContosoUser" instead of just "User", making SQL injection attacks more difficult to accomplish
Using port 55555 for SSH access on your servers, instead of the standard port 22, to dissuade brute force attackers
Obfuscating frontend code to make potential attackers have to figure out how the page works before doing anything to it
This practice has been subject to many strong opinions in the security field. I've personally heard from some in the field that it's a crutch for bad security practices, and from others that it's a very important tool. Let's talk about possible merits, and possible pitfalls as well.
The Vault Analogy
When considering different methods of security like this, I like to envision a vault, perhaps at a bank or what have you, with all your goodies inside. Your goal, of course, is to make sure no one successfully enters that vault.
Suppose your vault is kept in the back of your bank, and you happen to have the most top-of-the-line sci-fi cloaking system, that makes your vault blend in perfectly with the wall.
It's an analogy - Work with me here.
But the actual mechanism of opening the vault is incredibly simple: You simply press an inconspicuous tile on the wall, and the vault opens right up. No combination, no keys, no biometrics or other fancy stuff. You just have to know that you have to press the tile to get in.
Of course, this situation represents complete reliance on security through obscurity. If you have insecure infrastructure or software, and just rely on knowing what you know, that security through obscurity really isn't security at all. In the analogy's case, someone could potentially spy in and see an employee opening the vault. Or perhaps they manage to get in undetected, and simply start looking around and pressing on the wall, looking for hidden switches. This could be compared to things like port mapping, trying to just guess random ports and see if any of them gives positive SSH or RDP responses.
The opposite end of the spectrum is if you had a perfectly secured safe, with five keys required along with a combination, with super-reinforced adamantium protecting the goodies inside. That thing is NOT getting broken into. But instead of keeping it in a secure location, you put it in your lobby, letting anyone try to get in if they want!
This, likewise, represents neglecting security through obscurity, and fully trusting your technology and techniques to not fail you. This is certainly safer than the other end of the spectrum, but is it really a perfect situation? People trusted WEP encryption in the past, and we know how that turned out. People figure out ways around good technology. That's just how the world works. The goal, of course, is to lower the possibility of breaches as much as you can.
The Big Picture
I'd say that, in general, my opinion on the viability of security through obscurity looks a bit like this (In an abstract scale and brilliant MSPaint skills):
Obviously, with no thought given to security, you've established the lowest end of the scale. If you decide to rely fully on obscurity, you are substantially better off than nothing, but you could still do a lot better. If you fully rely on your technology and technique, you're safer than if you relied fully on obscurity, but if you layer obscurity on top of that, then you're slightly more secure than if you didn't.
I'd love to hear your thoughts on this issue, and your own opinions on the debate regarding security through obscurity. Happy coding!