Security By Obscurity

Security by obscurity is one of the most common ills that plague the software industry.

The most cited analogy for this practice is the act of burying your gold under a tree versus locking it in a safe. Hiding your gold under a tree is security by obscurity. You are relying on the secrecy of the act for the safety of your asset. If someone uncovers this act, you are busted. Also, this gives you a false sense of security.


Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

Recently my mesh router went kaput. I had to put in place a temporary alternative as internet connectivity is more important than oxygen these days. I had an old router given by an internet service provider. I tried to get it working with my current internet provider, but I could not. The router was locked to the provider. It would not work with any other internet providers. I tried to install OpenWRT on the router, but the hardware specs of the router were too low to host OpenWRT.

The other option was to change the custom firmware of the router to the router manufacturer’s default firmware. The manufacturer’s website had the steps to upgrade the firmware. I tried to follow the same. Strangely, the firmware upgrade section was missing in the router’s configuration interface. A bit of searching on the internet revealed that the internet company had removed this functionality from the interface, but if you directly go to the endpoint of the upgrade, it does work. They had just hidden this functionality in the interface. I did the update, and voila, unlocked the router.

This is textbook security by obscurity in practice. The internet company relied on only removing the upgrade link from the interface instead of eliminating the entire functionality. Anyone who discovers this is free to unlock the router. The right way to do it would have been to disable the feature as a whole. Not just obscure it in the interface.

Whenever you want to secure something, do not only rely only on obscurity. You can add obscurity as an additional security measure. For example, it is a common practice to change the ssh port on servers from the default port. Server admins do this in addition to a lot of other security lockdowns.

Photo by Tom Roberts on Unsplash

Software Security

Some disparate thoughts on security in no particular order.

Many security bugs can be avoided by making a clear distinction between authentication and authorization. When one logs into Facebook, one uses a username and password. Facebook lets you log in only once it is sure that you are the owner of the account by verifying your password. This is authentication. Once you log in, you cannot view all your friends’ photos. You can only view those photos which your friends have authorized you to view. This is authorization. There is a class of security bugs that arise because developers have not made this distinction.


A lot of security is knowing what not do. Security by obscurity and hand rolling security algorithms and protocols are the two things that immediately come to my mind. For example, while storing passwords, instead of coming up with an elaborate custom secure storage scheme, employ the industry standard bcrypt.

There is a thought process that you will do better security by having tons of access control. One of the manifestations of this is restricting SSH access to production boxes. Unless you have invested tons in tooling, this slows down teams drastically. In today’s world, where speed is paramount, this does not work. Under pressure to do things fast, teams find ingenious ways to circumvent these controls. Strict access control only works in organizations which are fine with taking things slowly but this usually stifles productivity and leaves a bevy of frustrated developers. The only way around this problem is to have the most necessary access control and take care of the rest through tooling. An example is how Netflix uses tools to enable developers to SSH into production boxes without compromising security.

Security implemented in a naive manner goes against the human nature of seeking to accomplish tasks in the least restrictive manner. If you do not invest in tooling, security always gets in the way of accomplishing things.

A less intrusive way of doing security is to configure systems with sane defaults. An example – when you provision a server, ensure that it is fortified by default. If you are using external tools, configure them with defaults. For example, if you are using Slack, configure it so that only people with your organization’s email address can sign up. Carry out a periodic audit of systems. This could be anything from periodically scanning SSH access logs to repository audits to ensure secrets and passwords are not leaked.

No writeup on security can be complete without touching upon compliance. There are tons – PCI, HIPAA, SOX etc. All these come with their own baggage. One simple way around this is to first understand what and all parts of your application have to be under the scope of compliance. For example, if you have an e-commerce application taking credit card information, you have to be PCI compliant. But this does not mean your entire application has to be under the scope of PCI audit. You can smartly bifurcate the application into parts that deal with payment and parts that do not. Once this is done, only the parts that deal with payment have to be under PCI scope.

A final note, security is a never-ending concern, there is nothing called enough security. Where you draw the line is up to you.

Here is a hilarious comic by XKCD on teaching a lesson to people who do not follow security practices.