Thoughts on "Security Through Obscurity"

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!

Probably unpopular opinion incoming: sometimes I feel programmers are lazy and use the obscurity as an excuse. Instead of designing a good API with nice return messages and senseful http status codes, they stress the point of security by obscurity: "if the API is not speaking a possible Intruder has a hard time".

I think it's definitely important. One of the biggest examples of this is the stack trace. During development you will want errors to be detailed giving you an instant insight into what the problem is, however once in production these will return a standard error message to the user. Hopefully you'll be logging these errors anyway, so you'll still have the ability to see what went wrong.

This means having different configurations for dev/test/prod something akin to:

In my experience, one of the biggest advantages to adding some forms of obscurity is that it can help improve the signal-to-noise ratio when you're looking for threats. For example, if I change all of my servers to listen for SSH on port 55555 instead of port 22, when I'm looking for suspicious behavior, I'll have a lot less data to sift through, since my logs for port 55555 won't include traffic from random bots scanning my servers. I will, of course, still enforce strong SSH key rules for my users.

To extend another example, if I call my users DB table 'ContosoUsers', an otherwise successful attempt at SQL injection will, instead of silently succeeding, raise a DB error. An error is a lot noiser and easy to spot than just another INSERT on users, so I can hopefully notice the attack sooner.

Slightly off-topic, but I like a Scooby-Doo analogy to security by obscurity – you may have a secret room with no visible signs nor means of entry, but eventually someone will try to take a random book off a shelf and click it's open.

You can add obscurity to your system, but please do not call it security. There can be advantages to the scenarios you suggest, but the security they add is just an illusion.

To go with your analogy, I would says that "security by obscurity" in bank is more like having various sings on the walls indicating that the vault is in a different location than where it really is. It makes it difficult for legitimate employees to do their job, but it doesn't deter determined attackers.

If, as a bank, you were to keep your vault in the middle of the customer area, it becomes a lot easier to notice when someone's been trying to pick the lock for half an hour. It may even discourage the casual criminal, knowing their deeds will be seen by all.

With any security measure, you have to weigh the security it adds, and non-security benefits, to the hassle it causes to legitimate users, and to the lengths people will go through to make legitimate use bearable. For example, if you require passwords to be at least 20 characters with at least 4 digits, 3 symbols, 3 uppercase, 1 emoji and not two consecutive digits, you can bet someone will write that password down on a piece of paper, and then your system is as secure as that piece of paper.

Great article, thanks for sharing. It seems easier to obscure things in the backend. For the frontend it's just a matter of time before your product is compromised. But if the object is obscured enough, say it takes 100 years to find, than yea that would be secure. But it's hard to make that judgement call as to how much obscurity is obscure enough, so it makes sense to me to play it safe and not rely on obscurity.

I do not get why people still think "security through obscurity (STO)" is a good idea in any form. As a developer, over the years I have seen and identified many STO instances; things people thought they got away with or they thought they were smart by implementing (including junior me).

The problem is they are not as obscure as everyone thinks; especially because so many people do it. All you are doing is shifting the problem to a different location.

STO is basically the dev equivalent of the delivery woman or man hiding your box under a rug.

One last thought, I really urge people not to do STO. We are in 2018, we have ways and means of protecting data and access to systems. If you are smart enough to obfuscate, there will be someone else smarter to figure it out.