Security through obscurity

Software security is always a topic of concern. The concept of Security through obscurity has already been criticized for a long time. This concept believes that the system is secure until the vulnerabilities are hidden and not known to the attackers.


This approach gives false hope of safety when, in reality, the underlying systems are susceptible to attacks. You never know when the vulnerability is exposed, and you have no time left to fix the problem.


Software security, especially in the banking industry is critical. The banks should follow a proactive approach rather than reacting to the problems exposed.

White hat hacking is the cool name for hiring hackers to detect any vulnerability of the system before being detected by the attackers.

This reminds me of an incident which happened while I was working with a large banking product. We were developing the product, and one of the available security feature was encrypting the URL parameters.

Encryption helped to prevent any data being logged or tracked by the middle-men or network teams. As per the development team, this requirement was complete and ready for testing. All the urls had some random string in them e.g.


http://www.example.com/params=afdh3sf345tfdjh45jf35h&fsh2ohg=fh@

We hired some white hat hackers to test our product, to proactively find out any problems in our system.
One of the problems raised by the team was that our encryption logic was not proper. Their concern was a set of characters were being repeated in every URL, and hence the logic of encrypting the URL parameters is not correct.


I spent a few days trying to test and simulate the issue in our encryption engine. I wasn’t even able to reproduce the issue, rather than fix the problem.


Then I discussed with the tester to understand more details about the problem. He told me that a specific set of characters was repeating in every URL. On observing the set of characters which were repeating, I randomly did a full-text search for those characters.


And yes, I found it. The root cause of the problem: a lazy developer, who did not want to use encryption engine in order to save some performance. So he named the variable with random characters (and also the values that he intended to give) rather than going through the encryption engine.
He preferred to encrypt his parameters by obscurity. No other human apart from himself was aware of his mischief. He believed that nobody will ever come to know that the URL parameters are not being encrypted.
Technical people will understand the following structure of the URL
http://www.example.com/params=afdh3sf345tfdjh45jf35h & fsh2ohg = fh@
It is easier to fool humans, but the automated tools bring out such vulnerabilities and help fix the issues.
That was a moment of a hearty laugh.

Published by

Mohit Kanwar

I am a software consultant. I design and develop web applications. I can coach teams to deliver good quality software, which is scalable and strong.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.