Security through obscurity is underestimated

In information security, we have developed a number of axioms that are not accepted to argue with:

  • Never implement your own cryptography.
  • Always use TLS.
  • Security by obscurity is bad.

Etc. Most of them are generally correct. However, it seems to me that people are blindly following these axioms as a cargo cult. And many don’t really think about exceptions to the rule. In this article, I will raise my objections to the idea that security through obscurity is bad.

Risk, Layered Defense and Swiss Cheese

One of the main tasks of information security is risk reduction. According to the OWASP methodology, the risk of a problem is calculated using the formula:

Риск = Вероятность * Воздействие

By this formula, the problem of remote code execution (RCE) poses a greater risk than the problem of cross-site scripting, because the RCE has a greater impact. Everything is simple here. But what about the probability metric? According to OWASP, the probability is defined as follows:

At the highest level, it is a rough estimate of the chances that a particular vulnerability will be disclosed and exploited by an attacker.

Thus, if we reduce the likelihood, then we reduce the overall risk. It’s good. In fact, this is very similar to the well-known concept of “defense in depth”. It is also called the “Swiss cheese model”.

According to this model, you need to build defense mechanisms in a layered model in such a way that even if an attacker passes the first level, he will be stopped at others.

Security through obscurity

So let’s talk about security through obscurity. It’s a bad idea to use it as your only layer of protection. If the attacker passes it, then nothing else will protect you. But it’s actually quite good as an “extra” level. Because it has a low implementation cost and usually performs well.

Let’s consider several scenarios:

  • On my server, SSH runs on the default port 22, and the credentials root:123456… What is the likelihood of compromise?

The probability is almost 100%, since hackers all over the Internet are brute-force services with standard credentials.

  • SSH runs on port 22 and credentials utku:123456… What is the likelihood of compromise?

Well, we have eliminated the danger of brute-force with standard credentials. The likelihood and risk are reduced. However, we are still faced with a ton of targeted attacks. Someone might guess the utku username since that is my real name.

  • SSH runs on port 64323 and credentials utku:123456… What is the likelihood of compromise?

We have changed the default port number. Will it help? First, we have eliminated the danger of standard brute-force once again, since it only scans common ports. What about the rest? I ran a small poll on my twitter to find out the behavior of people when scanning ports.

As you can see, many tend to scan only the standard and most popular ports. Thus, if you change the port from 22 to 64323, then you eliminate some of the potential attacks. You will reduce the likelihood and risk.

The same is true for software vulnerabilities. If a vulnerability is found in the Microsoft Remote Desktop Protocol, the entire Internet will start scanning port 3389. You can mitigate the risks simply by changing the default port.

Other applications

Of course, apart from changing the default values, you can use the same methodology in other areas. In some cases (not always) the following ideas can be applied.

  • Code obfuscation: Of course, this is common knowledge. Hackers are people too. If you obfuscate your code well, they’ll have to spend more time looking for problems. Eventually they may give up.
  • Random variable names for a web application: You can use random characters instead of friendly variable names. It can help in the same way as code obfuscation.
  • Symmetric encryption in the database: when writing data to the DB, use a function like encryption_algorithm(data, key)… Similarly, when reading data – decryption_algorithm(data, key)… If an attacker gains access to the internal code, then, obviously, he will be able to decrypt the database. But if, due to some vulnerability, an attacker reads data from the database, but does not see the internal code (for example, via SQL injection), then the received data will not give him anything.

Real life application

Security through obscurity is widely used in physical / real-world security. For example, the president is driving from point A to point B with a motorcade of 30 cars. But he doesn’t sit in his presidential car, lest he become an easy target. It can be in any machine in the tuple, and this reduces the risk of an attack.

Animals also exploit safety through obscurity – it’s camouflage. Stealth reduces the likelihood of being killed. Therefore, in the process of evolution, they acquired this ability.

Output

Security through obscurity alone is not enough. Best practices should always be applied. But if you can reduce your risk at zero cost, then you should. Obscurity is a good layer in the overall security system.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *