ALL Security is Security Thru Obscurity
1. not discovered or known about; uncertain.
In the purely literal sense, the concept of obscurity applies to every transaction on the Web. The HTTP request knows not, nor could possibly know, the actual response it will receive from the server. There is only expected response. Online nothing is certain until it is.
So every transaction, whether it’s for a web page, user login, API endpoint, form data, file download, whatever. Either happens or not. A request is made, data posted, file downloaded, access granted. Or not. Like Yoda says there is no try. Especially online.
For any given transaction, there is no way of knowing with 100% certainty whether the response will be successful. We have algorithms and probability curves that predict how things will go. But ultimately a request is made.. and a response is given.
1. the state of being free from danger or threat.
How exactly does the concept of security apply to online transactions? What does it mean when we say that a website is “secure”? First and foremost, there is NO such thing as 100% security. Anyone that tells you otherwise is either lying or ignorant. No amount of security hardening or clever policy ever can guarantee absolute security.
Instead, look at the individual transaction. It consists of a Request and a Response. All of the technical complexities boil down to basically a send-receive transaction. And the data doesn’t care one way or another. Think about it. Security is relative. Some data or access that is important to you, may not be important to everyone.
Request & Response
Looking at the transaction level. First there is the request. As discussed this could be any type of online request, post data, download, and so forth. Contrary to popular opinion, it’s not the request that determines whether a resource is secure. It’s the response. Any policy aimed at securing based on the request is utter folly at best.
Why? Because Chaos. Unpredictability. There is no way of knowing which requests will be made until they actually arrive at the destination. And by then, you better have it worked out what the correct response will be.
That is the essence of security on the Web. Responding appropriately, based on the security needs of the site, service, or resource. Data is neutral, it does not care one way or another. So it’s all about evaluating the request and responding however is necessary to keep data secure, or not secure.
All of that to ask the question:
Is ALL security security through obscurity?
Returning to the definition, “obscurity” is something not discovered or known about; uncertain. To help bring this down to earth a bit, let’s consider a few “real world” examples of common security techniques, and then ask if they are “security via obscurity”.
- Passwords. Obviously unknown (read: obscure) passwords are better than known passwords.
- Hashing. Same as with passwords. If the hash is known access is granted.
- Form tokens. Same as passwords. If the token is known access is granted.
- Cookies. Same deal as with passwords. Cookies known = access granted.
- Anti-Spam Captchas. Easy to pass when the correct response is known (not hidden).
- Encryption. Hmm let’s see, securing data by obscuring it.
- 2-Factor Auth. Hopefully your mobile device is not available to hackers. Ergo it is hidden (obscure).
- Facial recognition. If someone stole your face, they would have access.
- Other techniques. Many other security techniques and tricks are designed to obscure access and data. For example, with WordPress you can hide the version number, customize the database prefix, change the URL of the Login Page, and much more.
So at this point in the discussion, it would be safe to answer our question with an emphatic “Yes”; according to strict literal definition, all security is indeed “security through obscurity”. I would be so bold as to surmise that most (if not all) legitimate online transactions fall into this category.
Dealing with illegitimate traffic? Not so much.
Haters. Start Here.
So what’s the catch? Are there any exceptions that would nullify the “it’s all security by obscurity” thesis? Perhaps. It depends on perspective and of course may vary based on circumstance. This is where you could argue either way, and I encourage you to do so. Really think it through.
Consider the following examples:
- Filtering. Like validating data, sanitizing inputs and such.
- Firewalls. Generally Firewalls block unwanted requests.
- Blackholes. Honeypot-type security techniques block bad bots.
- Virus Scanners. Some virus scanners operate after the fact and not applicable. Real-time request checking scanners though.
Security techniques such as these deal entirely with blocking or otherwise handling unwanted requests. For example False Positives. Normal site visitors should not be dealing with your firewall. Likewise with filtering, it is aimed at preventing unwanted slash bad data from messing things up.
But are these security methods also just “security by obscurity” in disguise? Or is there some other, better way to classify them?
- If No: If such techniques function via anything other than security thru obscurity, then thesis is false.
- If Yes: Otherwise, if they work via obscurity, then the thesis is true.
Honestly I could argue this either way. Yet for the sake of discussion, and to sharpen the proverbial sword, I will argue that, yes, this second group of techniques operates via obscurity, and therefore the thesis proves true:
It’s ALL security by obscurity.
How do defensive security techniques like firewalls and real-time scanners work? What is happening “under the hood”? They block bad requests, right? Well, technically there is no such thing as “blocking” a request. You can redirect or serve some appropriate response, but ultimately every received request is met with some sort of response. Just the way it works.
So when some crazy hacker bot script whatever scans your site for known vulnerabilities to exploit, they are looking for a specific response. So then if your firewall, virus scanner, bot trap, or other defensive technique does its job, the desired response remains “not discovered or known about; uncertain” — the very definition of “obscurity”. Hence “security by obscurity”.
And our thesis proves true.
Dark to Light
Just thinking out loud on this one. Trying to shed some light on the subject, mostly in response to the seemingly endless parade of opinions on social media that discount certain techniques as ineffective or useless simply because, “well duh, that’s just security through obscurity bro.” Or even more laughable, the idea that adding layers of security is just “security theatre” and not worth doing. Well if that’s true, then why bother with things like passwords, encryption, and everything else. Don’t use any of it, because according to some folks, they just don’t work.
Are there “shades of obscurity”? Yes many. But ultimately, when you examine things at a fundamental level, you’ll find that obscurity always plays a role.
I’ve tried to be as thorough as possible in my exploration and discussion of the topic. There is a good chance however that I am missing something (most likely something obvious) that other perspectives will help to enlighten. Feel free to share your thoughts in the comments below.
I would like to comment, by first off,
VERY good essay and analysis of “the problem” in considering security. ALL security deals with, at some level, “obscurity”. The degree (depth) of obscurity is largely what will help determine how well-implemented your security strategy will be. This seems to be something that many “experts” miss completely when they rail against “obscurity” as being ineffective, and even DANGEROUS to place one’s trust in.
Those who have dealt with security in great detail (like yours, truly), see the best security strategies employ compatible and complimentary security “layers”, as a means of effective security. In other words, the less you tell the world what you have, and what you use in your backend environments, the better your security posture. This does NOT, however, replace maintaining your computing environment, upgrades (VERY IMPORTANT, as always), and keeping constant vigilance – by regularly auditing your logs and other “usual and expected happenings”.
I am aware that everyone may have his/her opinion on what should be considered “secure”, as opposed to “NON-secure” (“Insecure” is improper word-choice at this point – IMHO), but that does not make their view uniquely the only correct view about security. It is still a “learning-curve” that each one of us must continue to explore, as the playing field between “good” vs. “evil” is an ever-changing “constant”. This war between the Black-Hats and the White-Hats will continue so long as there still exists the idea of inter-connected machines!
This does remind me of a certain blog article from some years ago, talking about securing a wireless network. This (so-called) “expert” tried telling everyone to only use WEP-encryption, but not MAC-filtering, non-broadcasting of the network’s SSID, nor even limiting access activities by assigned local IP-Address! – Let’s just say, I had a lot of fun with the author of this ill-conceived article, and made an absolute fool of him – just by my fully understanding the technology, and how to apply ALL capable layers to my security strategy. If your wireless router, AP, etc. has all these secure capabilities, then why not use them? (As in, all of them together! — “Multi-layered Security”)
– Jim S. Smith