Security through Obscurity
I came across an interesting blog post the other day that caught my attention. The post contained a good, concrete example of an important security principle called, “Security through Obscurity”. The example presented a case of Security through Obscurity that was used in code, which we’ll discuss shortly but first we need to explain what exactly is STO (Security through Obscurity). Here is a quote from Wikipedia on STO:
“In cryptography and computer security, Security through Obscurity (sometimes, Security by Obscurity) is a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them.”
In other words, STO is the attempt to strengthen security by adding in design complexity or making certain aspects of the system secret. Here’s an example. It is common practice for web-masters to modify the banner strings of their HTTP server. The banner tells the client which flavor and version of the Webserver that is running. The Webserver flavor may be Apache, Lighttpd, or IIS, for example. This information can be useful to an attacker and, therefore, it is recommended for banners to be silenced or even display incorrect information. Now let’s take a look at this practice of changing your banner on your Webserver. Does this make it less likely to be attacked? Some folk might say yes, though everyone would agree that it doesn’t actually secure your Webserver in any way. Perhaps an attacker is looking for a particularly vulnerable site and passes by yours since he can’t verify which Webserver and version you are running. This is STO. You obscured certain details of your system in an attempt to add in security; this is Security by Obscurity.
OK, now to the coding example I stumbled upon over at the iPhone Development blog. Here is a snippet of code in the Objective-C programming language (the language used to create MAC and iPhone applications).
NSString *credentials = @"user:password";
In the line above the author defines an NSString Object called credentials that contains a user-name and password necessary for authentication at some other point in the program. Now, once the program is compiled and ready to be deployed, the user-name/password text can be found fairly easily in the binary. Here is how the author obscures this line of code:
NSString *credentials = [NSString stringWithFormat:@”%c%s%@%c%c%s%@”, ‘u’, “ser:”, @”pas”, ’s’, ‘w’, “ord”, @”@”];
In the above line, the credentials NString has now obfuscated the user/password, which makes the user-name/password harder to find in the binary but not impossible. A tenacious hacker with a lot of time on their hands will figure it out eventually. STO isn’t “real” security, but, depending upon your security requirements, STO might be all that is needed. It certainly should not be confused with true information security.


