SecurityTrails Blog · Feb 13 · by Esteban Borges

Security Through Obscurity

Reading time: 6 minutes

When you work as a system administrator, one of your main tasks is to keep your systems secure, and that includes applying system package updates, kernel patching, disabling unnecessary services, installing IDs and firewalls, and many other things.

One thing that isn't always mandatory is applying security through obscurity. We know this topic opens a lot of discussions within the infosec community, and that's exactly why we're writing about it—to answer questions and demystify the doubts that constantly surround this topic.

What is security through obscurity? (STO)

Known also as "STO," "security by obscurity" or simply as "secrecy," it's one of the ways systems engineers and software developers secure a system or an app.

STO is based primarily on hiding important information and enforcing secrecy as the main security technique. By using security by obscurity, some people think they are going to minimize the risk of getting targeted by an attack.

Examples of security by obscurity

To explain how security by obscurity works, we need to look at real-life examples. And the first example that comes to mind is this one:

Hiding the key to your front door under a nearby rock or the welcome mat. The principle is simple: your house will be "secure" until a thief discovers the key in its hiding place. That's when your house becomes vulnerable.

The same goes for building your house in the middle of the forest. Being surrounded by trees and shrubs, it's "secure" within that forest. However, as soon as someone walks in and discovers your house, it's vulnerable.

In the cybersecurity world, there are other real-life scenarios where security by obscurity is seen every day:

  • Hiding user passwords inside binary code, or mixed with script code or comments. This is a very popular technique that assumes the attacker won't read the code, and therefore, provides protection from any intrusion.
  • Changing the name of your application folder, for example from 'admin' to '_admin.' It may take longer, but if the attacker finds you are using '_admin', and there is no additional authentication or IP-based whitelist, he'll be able to jump right into your administrative area.
  • Using a different daemon port is a very popular technique for reducing the amount of brute force attacks against certain ports, such as port 22 on SSH. This technique works; however, once a dedicated attacker finds your SSH port is running on a different port than 22, he'll start targeting your new port anyway. A proper solution would be to disable password authentication, and limit logins by IP with mechanisms such as TCP Wrappers or a firewall.
  • Hiding software versions: While there are a lot of ways you can perform a banner grabbing attack, one of the most popular STO techniques is to hide your software version from the public. In the case of web servers, the Nginx or Apache version can be hidden, which can keep attackers from knowing if you're running a vulnerable and outdated version.

Is this a bad practice for cybersecurity? After reading our examples, you may have the answer. Or do you? It's really not that simple—let's find out more.

Is security through obscurity a bad thing?

The truth is, security through obscurity is good when combined with other security mechanisms and defensive rules. But if you rely solely on STO to replace real system security, all is lost as soon as its secrets are revealed. In other words, there's nothing bad about STO, there are only bad practitioners.

What's the right way to use STO?

STO can be a very effective way to reduce the chances of attack when used along with other security layers, such as IP-based restrictions, 2FA, TCP Wrappers, firewalling and the like. True cybersecurity professionals never underestimate the power of hiding, because they know it's an additional link to the whole security chain, and not just an isolated lock.

When do I need to use STO?

We know STO is a solid practice, but should it be used in all scenarios? While most people may think that hiding information is always good, it depends on the type of system or application.

Sometimes, how and especially where you hide data may make things easier for attackers to uncover your secrets, so double-check before doing it. And if you do, ask yourself this question: Is STO going to help me reduce the possibility or impact of an incoming attack? (Take a look at the previous SSH open port example for reference.) If your answer is yes, then use STO. If the answer is no, don't bother spending time on it.

How much critical data is really hidden in your online infrastructure?

What if your obscurity isn't so effective after all? If you're using STO as part of your cybersecurity defensive strategy, our enterprise-grade tool SurfaceBrowser™ may help you audit all your online assets to detect critical exposed information such as open ports, DNS records, IP addresses, SSL certificates and much more.

Are all my ports closed to the public? Or am I revealing a few critical ones to remote attackers?

With SurfaceBrowser™, finding this data is super easy. Just click the 'IP Blocks' option and you'll be able to analyze all your IP addresses and subnets and discover exposed open ports in seconds:

Are all my ports closed to the public?

Am I revealing internal subdomain DNS records by mistake?

All development teams create test, dev, trial, or supposed "internal" or "private" subdomains during the development phase. Unfortunately, they often forget to delete the DNS records, which leads to the massive creation of stale DNS records.

Stale DNS records, and even other active subdomain records made public by mistake, become a frequently exploited area of many organizations.

SurfaceBrowser™ enables you to filter subdomain by keywords, and also to download all the results for offline analysis, as shown in the following screenshot:

Filter subdomain by keywords

How much data am I showing on my online SSL certificates? Are there any websites running with expired SSL certificates?

Discover all this and more by clicking the 'Certificates' option, which will allow you to browse all existing and expired SSL certificates and filter the results by 'Company,' 'Creation Year,' 'Expiration Year,' 'Validity' or simply by all of them.

Browse all existing and expired SSL certificates

In this case, we were surprised to find that Target has only 6 valid certificates and around 3,241 expired SSL certificates, as shown in the following screenshot:

Unencrypted subdomains

Is there any chance you'll discover active apps and scripts running on those unencrypted subdomains? The answer may surprise you.

By using SurfaceBrowser™, you can find the answers to all these questions and examine the obscurity of your online infrastructure.


Security through obscurity is an old practice that is useful when combined with other strong security measures. Only in this way should it be used to minimize the impact of an attack on any organization. Being wholly dependent on it is far too risky.

Obscurity isn't only about hiding information from bad guys. It can also reside within your own infrastructure—when you don't have full visibility over what critical data is being exposed to the Internet.

Shine some much-needed light into your online infrastructure, and begin visualizing unseen areas of your organization from a centralized platform. Discover SurfaceBrowser™ , the number #1 enterprise-grade tool that will help you to detect all the unseen areas from your online assets.

Book a demo with our sales team today!

Esteban Borges Blog Author

Esteban is a seasoned cybersecurity specialist, and marketing manager with nearly 20 years of experience. Since joining SecurityTrails in 2017 he’s been our go-to for technical server security and source intelligence info.

Subscribe to the SecurityTrails newsletter
Sign up for our newsletter today!

Get the best cybersec research, news, tools,
and interviews with industry leaders