A ton of us are acquainted with a concept referred to as security by obscurity. The terminology has negative connotations within the infosec community – typically for the wrong reason. There’s minimal debate with regards to whether security by obscurity is bad per se, this is the case as it implies that the secret being obscured is the key to the entire system’s security. 

When integrated to a system that currently has robust controls in place, however, obscurity not just doesn’t hurt you but can be a robust inclusion to a cumulative security positioning. 

Good obscurity vs. Bad Obscurity 

The critical determination for if obscurity is good or bad reduces to if it’s being leveraged a layer atop robust security, or as a substitute for it. The former is good. The latter is bad. 

An instance of security through obscurity is when somebody has a costly home equipped with a sophisticated lock system, but the way in which you open it is merely by jiggling the handle. So if you do not know how to execute that, it’s really secure, but after you know it’s trivial to bypass. 

There’s security by obscurity: if the secret ever goes out: it’s the end. The idea stems from the notion of cryptography, where it’s sacrilege to base the security of a cryptographic framework on the secrecy of the algorithm. 

Camouflage 

A potent instance of where obscurity is leveraged to enhance security positioning is camouflage. Take up an armoured tank like the M-1. The tank is outfitted with some of the most sophisticated armour ever developed, and has been demonstrated repeatedly to be efficient in actual real-world battle. So, provided this every efficient armour, would the hazard to the tank in some way increase if it were to be coated the same colour as its surroundings? Or what if, in the future, when we possess the technology to render the tank completely invisible? 

Did we minimize the efficacy of the armour? No. Making a thing difficult to see doesn’t make it simpler to attack or compromise if or when it is found out. This is a fallacy that just has to end. 

OPSEC is an even more appropriate instance as nobody noteworthy within infosec doubts it’s authenticity. But to the ones unacquainted, what is OPSEC? This is Wikipedia’s definition: 

OPSEC: A process or procedure that detects vital data to decide if friendly actions can be seen by enemy intelligence, decides if data gathered by adversaries could be interpreted to be useful to them, and then pardons chosen measures that eradicate or minimize adversary exploitation of friendly critical data.  

So essentially, safeguarding data that can be leveraged by an enemy. Like, where you are, for instance, or what you’re doing. There are tons of instances: 

• There exist typically one or more decoy limos and helicopters in flight near to where the president is, and the purpose for this is so that the enemy is unsure which to attack. 
• When you perform executive protection or military maneuvers, you typically wish to keep your movement plans as private as possible to prevent providing the enemy an advantage. 
• People are encouraged to take arbitrary routes to and from locations that are not safe so that prospective malicious actors will not be aware precisely where to attack you. 

These are all concerned with the control and restriction of data. Or, to put it differently, obfuscating it. And if it was really a negative practice, it wouldn’t be deployed frequently on a daily basis by the militaries of the planet, the secret service, executive protection, and anybody who knows fundamental security operations. 

When the objective is to minimize the number or frequency of successful attacks, beginning with solid, evaluated security and including obscurity as a layer does yield a cumulative advantage to the security positioning. Camouflage achieves this on the battlefield, decoys achieve this when travelling with important personnel, and PK/SPA achieves this when safeguarding hardened services. 

An SSH instance 

Obviously, anybody with a scientific frame of mind would like to observe data. Data, data, data, I cannot make bricks without clay. In that spirit, we decided to perform some evaluation of the idea leveraging the SSH daemon. 

We setup our SSH daemon to listen on port 24 on top if its usual port of 22 so we could observe the variations in attempts to connect to each (the connections are typically password guessing attempts). The predicted outcome is far lesser attempts to access SSH on port 24 over port 22, which we equate to lesser risk to ours, or to any SSH daemon. 

We ran with this alternative port configuration for a singular weekend, and obtained in excess of 18,000 connections to port 22, and five (5) to port 24. That’s 18,000 to 5. 

Let’s state that there’s a new zero day out for OpenSSH that’s owning boxes with impunity. Is anybody coming forward to argue with that somebody unleashing such an assault would be equally probable to launch it against non-traditional port vs. port 22? If not, then the risk reduces by not being existent, it’s as easy as that. 

Reducing Impact or Probability 

Another basic way to look at this is via the lens of risk, whereby it can be calculated as: 

Risk = probability x impact 

This implies that you reduce risk (and enhance security) by performing one of two things.  

1. Minimizing the odds of experiencing an attack 
2. Minimizing the impact if you do undergo attack 

Including armour, or obtaining a better lock, or taking up self-defence, are all instances of minimizing the impact of an attack. On the other hand, hiding your SSH port, rotation of your travel plans, and leveraging decoy vehicles are instances of minimizing your probability of being hit. 

The critical point is that both strategies enhance the level of security. The question becomes one of which should you concentrate on at any provided point. Is including obscurity the ideal leveraging of my resources provided the controls that you have in place, or would we be better off including a different (non-obscurity-based) control? 

That’s a reasonable question, and probably if you have the capacity to go from passwords to keys, for instance, that’s probable to be more efficient than moving your port. However, at some point of diminishing return for impact minimization it is probable to become a decent idea to minimize likelihood also. 

Conclusion 

1. Security via obscurity is not a good thing as it replaces actual security for secrecy is such a fashion that if somebody learns the trick, they compromise the system.  
2. Obscurity can be really valuable when included to actual security as an extra way to reduce the odds of a successful attack, for example, camouflage, OPSEC, etc. 
3. The critical question to bring up is whether you’re better off by including extra impact minimization (armour, locks, etc.), or if you’re better off including more probability minimization (hiding, obscuring, etc.) 

A majority of people who instinctively go to “obscurity is bad” are merely regurgitating something they heard a long time ago and think makes them sound intelligent. 

Don’t heed the words of others. Think about everything by your own self.