Why You Need Security Through Obscurity



In the field of cyber-security, it is a common idiom that one should not rely on "security through obscurity". But what is meant by this? And how does one distinguish between solid, non-obscurity-based security mechanisms, versus security mechanisms that are based on the principles of obscurity?

This article posits that, in reality, every form of security is based off of obscurity, but that certain forms of obscurity are simply more robust and reliable than others. So when someone says "Security via obscurity is bad.", what they really mean is "Security via weak or insufficient obscurity is bad." This could simply be a matter of semantics. If one wants to argue about what is or is not "obscurity", they can hold any position on this matter. However, the semantics are important to understand, as it illustrates the underlying philosophy behind the principles of security, itself.

To demonstrate the concept of proper security through sufficient obscurity, vs improper security through insufficient obscurity, let us examine two hypothetical scenarios, that will serve as allegories.

In Scenario A, a home-owner wants to secure his house from intruders. So he installs electronic, key-code locks on all of the doors to his home. The keypad contains all 10 digits (0-9), and to unlock the door, requires the entry of an 8-digit password. This means there will be 10 ** 8, or 100000000 possible combinations. Given the amount of time it takes to attempt even a single combination, it may as well be considered nearly impossible to properly guess the correct password. No sane intruder would bother trying to enter through that approach.

Is this an example of security through obscurity? Technically, yes, because the correct pass-code is made obscure. It is hidden within the unfathomably vast sea of tens of millions of other possible combinations.

Now let us examine Scenario B.

In Scenario B, a home-owner, again, wants to secure his house from intruders. But instead of doing something like installing an electronic lock, he takes an approach that he feels is more clever. He does not install any doors on the house at all. Instead, there is a hidden floor-panel nearby, hidden beneath a layer of grass. And there is also a switch hidden nearby. If the switch is pressed, the floor-panel will open up, and one can drop into the floor-panel, which enters into an underground tunnel, that connects to the inside of the house.

But an intruder would not know that there is the hidden entrance. Nor would he know of the hidden switch. Instead, he would approach the house and see that there are no doors. He will scratch his head in confusion, think "That's weird. What the heck?" and give up and head home. Or rather, that's the intended idea. This, too, just like the security mechanism employed in Scenario A, is an example of security via obscurity.

Now anyone can easily discern that the security method employed in Scenario B is far inferior to that which was employed in Scenario A. But why?

This is a simple matter of mathematics. If there are 100000000 possible combinations to the pass-code in scenario A, and it takes 3 seconds to try a single code, it will take a person three-hundred million seconds (or about nine and a half years) of entering passcodes before the correct code is guaranteed to have been tried. But how long would the equivalent of such a brute-force-based method work in Scenario B?

If an intruder in Scenario B wants to "brute-force" his way in, he may start by tossing around as many hypotheses as he can, about what the entry mechanism is. For example:

Maybe the door is a hatch that is hidden on the roof.

Or maybe one of the exterior walls is actually a door, disguised as a wall.

Or maybe there is an underground tunnel nearby, that connects to the inside of the house.

If he simply throws many ideas out there, one of his ideas is likely to involve the correct answer, regarding how the entry into the house is intended to work. If he tosses around, say, 10 ideas, one of them is likely to be correct. If he then spends but a few hours investigating each of these ideas, one at a time (e.g by climbing to the top of the house with a ladder to search for an entrance of the roof, or surveying the surrounding area to search for underground tunnel entrances, e.t.c), it will take him only a few dozen hours before he will have gained entry to the house.

Therefore, Scenario A is simply far more secure than Scenario B. Not because Scenario A involved less obscurity, but because it involved a greater degree of obscurity, based simply on the math involved in how long the code takes to crack.

Scenario A can be compared to a WIFI network requring a password for access to the network. Scenario B can be compared to a WIFI network operating by rejecting non-whitelisted MAC addresses. Scenario B (and it's cybersecurity equivalents) rely on the intruder getting confused and giving up. It relies on the intruder not understanding how the mechanism works, and not being able to figure it out. Whereas Scenario A (and it's cybersecurity equivalents) allow for the intruder to understand the security mechanism, but makes it largely impractical, and nearly impossible, for him to crack the obscurity through brute-force guessing.

If in Scenario B, the intruder correctly guesses that the WIFI access point is simply rejecting his access because his MAC address is not in the whitelist, and spends ten seconds changing his MAC address, the security mechanism is rendered useless. If the situation involving Scenario B were such that there were tens of millions of approaches that the intruder would have to try before being likely to stumble upon the correct one, then it would be equally secure as requiring a pass-code. But that simply isn't the case.

When one thinks about it, it becomes apparent that every form of security (even physical, non-cyber security) is based on the principles of obscurity. For example:

A traditional, key-based lock requires on obscurity, because if an intruder knows how the lock is constructed, and the length of each pin in the pin-and-tumbler locker, he can simply manufacture a key that will fit the lock.

Or to use some more technical, nerdy, cyber-security examples:

When performing a buffer-overflow attack, the address space of the data is randomized, thereby making the location of the intended payload (the shellcode) more obscure, and harder to guess.

Operating systems, compilers, and loaders also often use "stack canaries", in which a small randomized code is placed just before the return address of a function, so that when the function ends, before execution is returned to the return address, the value of the stack canary can be checked to see if it has been changed. If it has, the return address is no longer deemed safe, and the program can simply crash, rather than risking jumping execution to an attacker's payload. The canary is randomized - or in other words, it is made to be obscure.

In cryptography, the key to decrypt the ciphertext is obviously randomized, and therefore, also made obscure.

So in every case of security that one can think of, everything boils down to obscurity (often through randomization). So when designing a security mechanism, rather than asking "Does this security mechanism avoid obscurity?", perhaps it would be more wise to ask "Does this security mechanism provide sufficient obscurity?". Security is, therefore, not a matter of obscurity-vs-no-obscurity, but is instead of a matter of good-obscurity-vs-poor-obscurity.