Obscurity can be fine but it's not security. I think of it like cover and concealment in the military. Security is cover. Something you can get behind so the bullets don't hit you. Obscurity is concealment. Harder to see, harder to find, so the enemy doesn't know where to shoot, but it's not stopping any bullets. Both have advantages and disadvantages and can complement each other depending on how they're used.
Example: there are teenage gangs going around on high powered scooters in my city, carrying hammers and mini grinders. They pair up on a scooter, steal a bike and disappear.
I watched them. They don't want to hang around longer than necessary. They will only approach a bike rack that is clearly visible from the road. They will only steal a bike that has unobstructed access to the road (no tricky bollards or other bikes to get around). Even though they are full of bravado, and shout obscenities and threats at me when I tell them to fuck off, they still run away (even though the one approaching the bikes is carrying a weapon while his companion stays on the scooter ready to escape)
Anything that even mildly inconveniences these guys is enough to stop them attempting theft. The bikes they steal needs to be expensive, out in the open, with direct access to the road, and with a shitty lock. And believe it or not, those tumblers line up a lot.
Throwing a blanket over a bike is probably enough to stop them from even approaching it.
That's fine as long you are really clear in your mind about what's going on.
It IT there are a lot of people tossing a blanket over the scooter and believing they're affecting the ability of the the attacker when they're really changing the likelihood of an attack.
Imagine if every single person put a blanket over their bike. Now imagine if everyone got a chain that was 10 times stronger. Which world would you rather live in?
Honey pots, tar pits, bot motels, janky configs, visible telemetry (for example): these slow down adversaries in two ways. 1) They directly slow the adversary down and force them to navigate deliberately. 2) They increase uncertainty in uncomfortable ways, the effectiveness of this depends on how important it is for the adversary to remain undiscovered, not "poke the bear". Together, the effect is more than additive.
In addition to likelihood, attacks have shape. And proper installations can force your adversaries' maneuvers to take a certain shape. I've heard this referred to as terraforming.
If you're going to "do it in the road" (a highly visible bike rack), your lock or chain works much better when it is better / stronger than the herd. If everyone has a chain which is 10x stronger, then a better grinder becomes a cost of doing business. Maybe I'd rather live in a world where I didn't use that bike rack.
This is an especially good analogy because facing a well-resourced adversary in cybersecurity is like finding out that the enemy brought artillery -- hopefully you weren't relying entirely on obscurity because pretty soon there will be nowhere to hide
Funny analogy, in that when the high caliber shells start raining, most forms of cover won't make a difference. The ones that will, are not something you want to stay behind on days when you're not being actively bombed. In fact, keeping you behind such protections is by itself a military tactic - it lets the enemy roam freely and maneuver around you.
But the basic flaw of this analogy is that it implies you're at war, and your system is always in battle.
Agreed with your sentiment, and that was a great example.
Just like any security control, if it's your only means of security, it will not offer much risk reduction. Just like all security controls, the if you want risk reduction use more security controls together. Like all security controls, there is no way to eliminate risk, just reduce it as much as possible while still being able to effectively achieve your mission.
Because of this I believe security through obscurity to be important component in a healthy and mature risk posture.
It irks me when it's dismissed because obscurity is not security. No single security control is security on its own.
Think about leaving your bike unlocked in times square, vs. the top of a 7 000 meter mountain in the himalayas.
Which unlocked (unsecure) bike is more likely to be stolen, and ergo has a lower risk attached?
----
Obscurity does not help you when the thief has already found your bike, nor is obscurity very helpful for keeping your bike safe if you happen to live in times square.
But if you live at the top of a himalayan peak, you can be fairly certain you're not going to have your bike stolen.
the security controls for a bike on a high mountain are not obscurity, they're the lack of oxygen (that kills), the cold (that kills), the height (that kills), and the literal sheer difficulty of getting there.
you could put the bike right on the side of the mountain without any obfuscation and it won't get got because ain't no one gonna die for a bike.
its like how we know where dead people are on Everest but we can't get them down; they serve as landmarks.
I don't think that really works because obscurity isn't harder to see or find. I don't know the analogy, it's like standing out in the open and being like "yeah but who would think to look here lol".
I think you're misinterpreting "obscurity" for "lack of obscurity". If you have a vulnerability in an API interface that is completely undocumented that is a vulnerability that is obscured. It's hiding in the woods, not standing in a field.
To keep with the analogy: no one is going to stand in a field when people are shooting at you. So then why do a small subset of vocal people online suggest that you just put your bulletproof vest and claim that hiding in the woods, regardless of the vest, is a bad idea?
You know when people are shooting at you. You don't know when or if people are exploring undocumented/obscure features of your system and what they have learned about it that you were trying to hide.
Therefore, the safest assumption to make is that an adversary already has figured out all of your obscurity, because they always can do this given sufficient time and interest, at which point the only thing between them and you is your security.
That is why we design systems without obscurity and only care about security.
I agree that it's a good principle but it's taken too far when justifying needlessly growing risk surface area. Like the principle is useful to justify security hardening. It is not useful when used to increase the odds of being attacked.
Obscurity is not worthwhile when it increases your own costs. Nevertheless, if you can add obscurity with negligible additional cost and inconvenience, then you should do it.
This isn't about what's a good idea or bad idea. Perhaps it's best to simply leave analogies behind, otherwise we'll just focus on the wrong thing.
Security through obscurity merely means that your system is atypical. It's not hidden, it's not secret, it's not hard to find, it's not hard to examine, it's not less visible, etc - there is nothing inherently different about the systems at all other than that one is more common than the other. It's just less typical.
What you're describing is a thing that is not obscured. Don't refer to things as obscured if they are not obscured. When others talk about about things that are obscured they are talking about things that are obscured, not things that are not obscured.
I'm having a hard time understanding what you mean here. If something is obscured, by definition it is less visible. Being 'less typical' is a form of security because most attacks rely on some form of pattern recognition, and obscurity literally dissolves patterns into noise.
You're overly focusing on the term and not the meaning. The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often.
This notion was termed "security through obscurity" ie: "you use the less popular option, therefor that option is safer". It has nothing to do with "obscuring" in the sense of "hiding", that's a linguistic quirk of a colloquial term. If you were actually taking action to reduce the ability to understand a system in a way that you could meaningfully defend, it would no longer be "security through obscurity".
The argument has persisted because there are two different questions that sound the same (X is less typical than Y):
1. Is "X" safer than "Y"?
2. Is a user of "X" safer than a user of "Y"?
When looking at (1) in isolation, you can say things like "X lacks security features, therefor Y is safer" and "X is less often used, therefor X is safer", etc. This is a question about the posture of the project itself, in isolation.
(2) is about the context for users. The reality is that X, which perhaps is fundamentally less well built software, may actually have users who are attacked far less frequently.
Both are likely to favor "rarity is a poor indicator of safety" as we generally reject mitigation approaches that rely on attackers to behave specific ways, but what's important is that these are completely different questions and neither has to do with being obscured but rather rare.
None of this is about what is "obscured" or not. If something is obscured or obfuscated, that is a technique that can be evaluated separately by its own merits (ie: how hard is deobfuscation, how easy is it to adapt to deobfuscation, etc). All of this is about whether you're evaluating (1) or (2) - and in the case of (1), which is what the criticism always has focused on, the answer is that "rarity" is not a mitigation.
> The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often.
Visiblility is also a mental construct of what we expect to see and what we know already and can map to what we see. "Obscure" is doing a lot of work here. It doesn't necessarily mean hidden, it can mean the object's true purpose or form is hidden from some particular vantage, and only that vantage.
>If something is obscured, by definition it is less visible.
Obscurity is not the same thing as something being "obscured".
Obscurity means something is either difficult to comprehend, not well known or uncommon.
Obscured means something is hidden or concealed. When something is hidden, that means the thing is still there and there is a way to get to it. You can build automated tools around finding it.
>Being 'less typical' is a form of security because most attacks rely on some form of pattern recognition, and obscurity literally dissolves patterns into noise.
This is making the leap of faith assumption that "obscurity" is equivalent to "impossible to understand". In security you have no control over the attacker and therefore have to assume your attacker has more than enough knowledge and intelligence to perform the attack.
Since computer systems are static and unchanging without frequent patching, you can't assume that there is a cat and mouse game where the mouse is adapting its hiding strategies dynamically and managing to escape every single time.
Depends, some systems are dynamic. There is also a gray area where obscurity can be computationally infeasible to attack, but not bound by traditional polynomial assumptions in cryptography.
As is always the case in these semantic discussions, the answer depends on your initial axioms and assumptions, which does kind of make most of these discussions pointless (but I did learn a lot from this one).
Interesting. Have you seen the movie Braveheart? That's the leadup to the later humiliation of the king in battle, there's a movie / drama about this one too. Saw it recently, don't remember the name.
Basically the insurgents choose terrain they know well, because they live there. They choose a swamp / mire in an open field between two hills. They build fortifications. They obscure the true nature of the ground they're standing on, out in the open. They goad the king's army into finishing them then and there. They fight on foot against knights on horseback. It's a mess. They win.
Security through obscurity is mitigation basically. You reduce risk/impact, not eliminate it. There are problems - such as denial of wallet attacks - where you can only mitigate and can't eliminate the problem completely
the implication of the "don't be acquired" and "don't be penetrated" is some sort of anti-air or anti-tank missile.
"killed" in this case would be equivalent to having something penetrate and hit sensitive systems. at that point it's basically just a function of what the penetrator is trying to do -- if they just want $$$ they ransomware. if they want exfil or DoS or making critical systems do naughty things that is also a kill.
> the implication of the "don't be acquired" and "don't be penetrated" is some sort of anti-air or anti-tank missile
not necessarily - this model is also taught for army/marines type ground combat operations, in how to effectively camouflage, how to manoeuvre.
the "don't be penetrated" is more of an equipment choice and engineering decision specific to armor and active kinetic counter-munitions systems, like anti-drone shotguns, tanks with active protection systems, chobham armor, etc.
If a munition has been fired by you, first try to not get penetrated by it at all, and if that fails, try to prevent something catastrophic like a bolus of explosive formed penetrator molten copper from spraying into the inside of your armored personnel carrier.
The problem with that statement is that a lot of people who yield it fail to see the advantages that come with these extra shenanigans ; and let's just take pure concealment so I don't pushing weird arguments ; in the age of AI - each time we are able make an attacking AI misaligned we are essentially buying time ; an on-going attack is never a on-shot event ; it's an ongoing process where the attacker has to understand where it is located and what it can do ; since each element will be a resource ; do not let it have it in the first place.
It's a bit of an elitist view of security that romanticize concepts without thinking about what they can actually be used for. My personal bad experience with that was a manager who was stating me that having a different subdomain for the admin panel was a concealment and not a security practice.
I mean - it's very easy to see how this kind of argument actually prevents from doing something that can help just on the basis of philosophical purity - which often just miss the point - security is not a mechanism that will solve all your problems ; heck in fact I have to layer at least 4 mechanisms just on the http interface to feel safe ; it's more of a lot of layers that together form a barrier ;
We sit too much on TLS thinking "That's it, security job is done" - then we get some crazy stuff like French ANTS that get pawned with some IDOR ; as IF f* using some hash or something ; ANYTHING PLEASE F* HELL ; would have not helped
> All modes of cyber security depend on some obscurity (e.g. password)
That's not what the expression means.
"Security through obscurity" has a very specific meaning — that your system's security depends on your adversary not understanding how it works. E.g. understanding RSA is a few wikipedia articles away, and that doesn't compromise its security, so RSA isn't security through obscurity.
Lucketone likely knows this and was pointing out that "obscurity" is a misleading word to use when talking about systems which all rely on obscurity, in the plain English sense of the word.
We're in a technical forum, discussing a term of art that refers to a very specific bad practice.
Lucketone's argument is essentially saying that the bad practice itself isn't actually a bad practice by equivocating the term of art and the plain language definition.
The problem is that the term of art is confusing to technical people. See TFA. Technical people make logical leaps from "avoid security through obscurity [in the specific context of security systems which depend on obscurity and for which there are better alternatives than obscurity]" to "you should never obfuscate JavaScript" because the word is imprecise.
No, "Security through obscurity" is a valid and useful layer. A lot of weight hangs on your word “depends” though, in which case if it is the only layer then you will eventually have, uh, problems.
I’ve used it for a long long time. Like in 1999 I’d have a knock on certain ports in a certain order to unlock the ssh port.
And lots of weird stuff to stop forum spam. Which could work for weeks or months or even a year.
Port knocking isn't security through obscurity. Given the knowledge that you have a port knocking system in place doesn't tell me what specific sequence of knocks will open up the service I want to target. Even just a two knock sequence gives you a key with 32 bits of entropy, which makes it trivial to block attempts at bruteforcing the key.
Yeah absolutely. That was precisely my point — Requiring a secret (be it a password or the private part of an asymmetric key) isn't security through obscurity, and finding the sequence of knocks is equivalent to finding a password of equivalent complexity.
In cryptosystems there is a difference between things that can be changed and not, eg passwords/keys are a secret that can be easily charged. Algorithms not so much.
"Security through obscurity" refers to the practice of using an hard to change "thing" as a secret, which is indeed bad practice
Security through obscurity in cryptosystems would mean defining your own crypto algorithm (or using a secretly-defined one, secret in the sense that it is unknown to the adversaries) to protect your system.
It is NOT bad in itself. It IS bad if you only rely on that. Even if you'd use a "secret" algorithm, you MUST protect the keys as with a public algorithm. Also, being secret means you cannot benefit from the cryptanalysis of the community, which is in practice very important. BUT... if you have a lot of cryptanalysis expertise at disposal, then using a secret algorithm can be very effective.
i don't know a lot about the subject, but the little i know tells me this is not the way to look at this
your password (plain text) is secret because only you are supposed to a have it. in the digital realm, sharing the contents of the password (plain-text) is be akin to making a copy of it — undesirable
now, the algorithm that hashes the plain-text for comparison with the stored hash, that can be know by anyone, and typically is
It does seem to be a word game, because "it's not stopping any bullets" either isn't honest (it does stop bullets from hitting you when the enemy doesn't know where to shoot) or it's limited, just like obscurity is ("it may stop a few bullets, but it won't stop all, and there will be other weapons it can't stop either"). I think public key exchange is considered security, but it still requires to obscure your private keys.
Perhaps a better word would be resistance (to intrusion), which is a dimension orthogonal to visibility.
All security is security through obscurity. When it gets obscure enough we call it “public key cryptography”. Guess the 2048-bit prime number I'm thinking of and win a fabulous prize! (access to all of my data)
> Security ONLY through obscurity is bad (Kerckhoffs's Principle).
This is the crux of the article.
(1) Kerckhoffs's Principle doesn’t say that. It says to design the system AS IF the adversary has all of the info about it except the secrets (encryption key, certificates, etc).
(2) this rule is okay if you are a solo maintainer of a WordPress installation. It’s a problem if you work at a large company and part of the company knows the full intent of this, while the rest of the company doesn’t know the other layers of security BECAUSE of the obscurity layer. In this way, it’s important to communicate that this is only a layer and shouldn’t replace any other security decisions.
Kerkhoff's principle is not about security in general, it is about the design of cryptography. Assume your opponent knows everything about how your crypto system works. Your security then lies in the keys and not knowledge of the method.
More broadly, anything that raises the cost of an attack helps security. Whether it is worth investing your defensive effort in that vs on more actual security is a different matter.
If it does not obscure your own view of the security or reasoning about the security stance.
For instance, with respect to url parameters, I have seen people being told they have an Insecure Direct Object Reference, then apply base64 encoding to it to obscure what is going on. To QA they don't notice it looks like junk, it is obscure, but base64 encoded parameters are catnip to hackers.
So in this case, the obscurity made the system worse over time.
Heck, the most cringeworthy phrase "Base64 Encryption" which I have heard many many times.
But I think it's covered by your immediate parent comment
> Whether it is worth investing your defensive effort in that vs on more actual security is a different matter.
So the base64 introduces a marginal security gain, but in addition to expending effort in implementation, it increases the cost of other efforts (which is the case for almost all features), in the case of a fixed cost QA (which is again, always the case), the quality of the QA (pardon the redundancy) will be the parameter that suffers.
So yes, if the security gain is very minimal, then it's likely that the cost of the feature will be so great comparatively, that it will not only affect all other parameters like ease of use, but the negative indirect impact on security
will be greater than the marginal positive direct impact on security.
I agree, that anything that raises the cost of an attack may be worth doing. Most “obscurity” related practices do not meaningfully raise the cost of an attack beyond a certain threshold. Physical locks are not a great analogy.
The example in the article is more likely. Changing the name of a DB table from the default helps because any low quality probe script will break as soon as this assumption of default errors. It means that low effort, low tech, low talent attacks will fail. This is not a bad thing because these are likely to be the most common kinds of attacks.
Again, I'm not opposed to simple tricks like this to “buy some time” so long as they don’t PREVENT the deeper layers of security from being performed. But if a company has scarce resources and a choice between patching unpatched software or changing DB names from the defaults the former actually improves security and the latter should only be performed if the staff has solved all of the higher risk items.
But it can add a bit of delay to someone breaking actual security, so maybe they'll hit the next target first as that is a touch easier. Though with the increasing automation of hole detection and exploitation, even that might stop being the case if it hasn't already.
The biggest problem with obscurity measures IMO is psychological: people tend to assume that the measures⁰ are far more effective than they actually are, so they might make less effort to verify that the proper security is done properly.
----
[0] like moving SSHd to a non-standard port¹
[1] a solution that can inconvenience your users more than attackers, and historically (in combination with exploiting a couple of bugs) actually made certain local non-root credential scanning attacks possible if you chose a high port
Obscurity can be combined with security for much better results. Machines as well as AI in extension thrives off patterns and making illogical off-pattern decisions is usually to the benefit of the defender, not the attacker. As you said, the attacker has a wide attack surface to cover while the defender only has to fortify his home NAT. E.g. port knocking may very well throw off the hoard of scanners on the wide net simply because its not standart and the combination is known only to you. Similarly, fail2ban may not work as well on a standart SSH port, because every attacker is going to hammer that and one may get your misconfigured password root login right.
Now, in both instances, the obscurity provided does not necessarily cure your infrastructure's vulnerabilities, a dedicated attacker wouldn't have a single problem with either of these. But for someone who hammers the whole internet in a dim hope of finding another Wordpress server from 2017, or the latest flawed online security cam, your disguise is as good as perfect.
No this is not what GP said, and I don't get how you reached this conclusion. This is like saying that AES is security through obscurity because it relies on key being secret. See [1] (linked in the OP) to understand the difference better.
I am pretty sure everyone who works in security agrees that obscurity is not security.
no because it's still possible to find the data using standard techniques, it doesn't count as obsecurity it's still possible.
I.e. just because you* don't know where something is, doesn't mean it's using obsecurity to hide.
The reason is important, because words mean things: If you say, knowledge of some secret is security though obsecurity. That means passwords are security though obsecurity.
*: that may or may not be available to the attacker.
it other words, just because a secret exists, doesn't put that secret into the 'obsecurity' category.
That's not what security through obscurity means. Security through obscurity has a specific meaning, it doesn't just mean to gain security by hiding anything it means to attempt to gain security by hiding how a system works.
ASLR is a well understood system that exploit writers know to expect and thus ASLR is not security through obscurity.
The point of ASLR is that even if you fully understand how it works, this won't make it easier to bypass the protections of ASLR, since the primary way ASLR works is through dynamic adaptation. This turns it into a probabilistic security technique where there is always a chance that an attack goes through.
Security through obscurity in this case would be to roll your own ASLR implementation with a different randomization strategy.
The other thing though is that there are situations where you only have a limited amount of tries for a password, and incorrect tries can have dire consequences. If you are being asked for a password by an armed guard, and you hack the system completely and get the password, but didn't know about the last obscured step that you were supposed to type it with your left hand, not your right, you will still face whatever consequences even though that step didn't add any security.
As a fan and believer of obscurity in support of security, I do not understand why
> that step didn't add any security.
It is a decision that’s part of the entire process. A branch of many in the decision tree. Other branches are deciding which characters to type for the password; ASCII characters can be as little as 1 bit apart. Deciding between left and right is also 1 bit apart.
I think it boils down to what people commonly understand to be publicly knowable information versus understood-to-be-secret information.
One example: I self-host my password manager at pw.example.com/some-secret-path/. That extra path adds as much to security as a randomly picked username in HTTP Basic Auth: arguably none. Yet, it is as impossible for attackers to enumerate and find that path as it is with passwords.
The difference is that the path leaks easier. It’s not generally understood to be a secret. Yet I argue it helps security. (Example: leaking the domain name through certificate transparency logs AND even, say, user credentials means an attack is still unsuccessful; a strictly necessary piece of the puzzle is missing).
The delay can also be infinite in practice. If a really bad zero day is discovered, it might protect you from becoming a victim. No guarantees, but it can improve your chances.
Totally agreed, to me data is just like code: extremely valuable for the functionality it provides, but in most other ways a serious liability. That said:
> I don't think "obscurity" really buys you much (especially these days, with LLMs).
Actually I think it does so even more with LLMs. As has been posited before (particularly on the threads about open source projects going closed source) security comes down to who has paid more attention to the code, the attacker or the defender. And of course, these days attention is measured in tokens.
We know that LLM's are pretty capable of reversing-engineering to figure out an application's logic, but I would bet it takes many more tokens than reading the code or other public information directly. As such, obscurity adds an important layer to security: increasing the costs on the attacker.
Security has always been a numbers game, but now the numbers will overwhemingly be tokens and scale. If the defenders can cheaply raise the costs on the attackers by adding simple layers of obscurity, it can act as a significant deterrent at scale. I wonder if we'll even see new obfuscation techniques that are cheap to implement but targeted specifically at LLMs...
The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.
One example I remember is Pidgin storing its passwords in plain text in $HOME. They could have encrypted them with some hardcoded string, and made a lot of people happy that they would no longer grep their $HOME and find their passwords right there. However this had the side effect that now people were dropping the ball and sharing their config files with others. Or forgetting to setup proper permissions for their $HOME, etc.
In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.
Why a hardcoded string and not a user specific password the user used for pidgin? Then you’ve got real security and even using a password stored in the user’s keychain means that the passwords are not trivially accessible.
The whole point of security in depth is that you use non colinear layers of protection to raise the cost of an attack and reduce the blast radius of a successful attack.
Pidgin predates keychains, but if I remember correctly you had the option to set up a master password or to simply disable storing passwords, which were the only options that were truly incrementing security. But most users would not do that (they want autologin for a reason), so the example still applies.
(Note also most keychain implementations are not truly improving security in any way, but this is a separate topic)
> The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.
I almost missed the twist at the end because I had no idea what the hell cockroach papers were. I still don't understand the reference, but at least it sounds mildly interesting. So, well done.
Now, as for this strawman argument of yours about justifying an infinite amount of crap, that's true of all manner of disingenuous arguments. Who cares about that in this case?
> Or forgetting to setup proper permissions for their $HOME, etc.
This is Pidgin's fault how?
Now, if you wanted to argue that Pidgin should have put the passwords into a separate file and chmod400'ed it that would make much more sense.
> In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.
Not many good things have zero cost, do they... The point of TFA is that a little bit of well thought out obscurity pays huge dividends when applied in the real world. His example about the WP exploit ought to be all you need to read to get on board with that.
Security ONLY through obscurity is bad (Kerckhoffs's Principle).
Security through obscurity, as an additional layer, is good!
I've been saying this ever since that phrase was coined. A layer or two of obscurity keeps a lot of noise out of logs, reduces alert fatigue and cuts down on storage costs especially if one is using Splunk as their SIEM and makes targeted attacks much easier to detect. I will keep it.
The informed claim is not that the obscurity layer has no value. Quite the contrary, it has such a great value that it basically reduces the incentives to have great proper security and thus once the obscurity layer is breached the second line of defense is weaker.
The argument is that it's much easier to secure proper key material rather than design and config information that can often be leaked accidentally because it's actually directly manipulated by humans (employee onboarding, employee churn etc)
That's an interesting way to describe it. It's kind of like the turn away from requiring regular password updates. On paper, password rotation is good. But when you consider its interaction with human psychology, the policy makes security worse by causing people to make bad decisions.
It would be nice if there was no overlap between terms for the operational things that help improve security (log reduction and other non-cryptographic methods of reducing admin fatigue), and the mathematical cryptographic characteristics of the system.
If the focus is on the latter, obscurity buys you nothing and adds complexity/distraction, which is bad. The former can be important though.
Yeah, I always thought that real security is priority #1. But, using convenient obscurity lowers the obvious attack surface to things like automated scanners, just a bit.
> Security through obscurity, as an additional layer, is good!
If and only if the security advantage it gives outweighs the the numerous disadvantages.
It never* does. That's why the comment calling it bad got so many upvotes. Mixed in with those cargoculting the meme, are people like me who have had to deal with obfuscation techniques, written by someone else, that the bad guys understood before I did.
Obfuscation as a security measure is bad, because it feels like it's positives can compete with it's negatives; but that's rarely the case.
I might, depending on how much objective evidence you'd demand for substance. The problem with obscurity as a security feature, is the group(s) that feels the impact the most. Heuristically, you can create 3 groups that are impacted. APTs, skiddies, devs/maintainers.
Obscurity will stop skiddies... effectively 100% ....but so will everything else. Regular updates, and a half good password also stops skiddies to effectively 100%. Obscurity has a net negative effect on the system because it doesn't increase the attack cost on skiddies, but does increase the maintenance cost to engineering. This is the vast majority of attackers you'd want to deal with.
Your Advanced Persistent Threats, will be slowed by some amount of obscurity, but they will not be be stopped by it at all, at best it's a road bump. Persistence and intent will overcome any amount of obscurity. Same idea as give enough eyes, all bugs are shallow. Given enough time, any/all amount of obscurity will be understood by the baddies.
The downsides to obscurity is it's cost both to maintenance of the system as a whole, but also to the heuristics non-security developers use to find/understand bugs. Obscurity introduces significant complexity into the system. That complexity makes it harder to find and understand real bugs, but worse, it also obscures the security of the system itself to non-experts. I do believe we'll never escape the reality that most developers see obscurity, and think "this 'secret' makes this secure" but obscurity is *not* a secret. It doesn't provide additional security/safety. It only marginally increases the time to find and deploy the exploit. Here, this extra layer of obscurity actually decreases security because developers will stop looking for ways to harden the system, because this "secret" is good enough. I.e. the obscurity added only has the opportunity cost replacing the effort that would have been spent on real security.
If you have a full security team managing the obscurity the maintenance cost to the system, will be less than the cost to your APTs, but if you don't have a full time team working on it (or at least a strong expert in both how obscurity benefits the system, but more important, a strong expert in real security), the maintenance costs will exceed the time/delay until exploitation.
It's likely that I could deploy some system securely, with obscurity layered over top. But I often don't because I don't wanna deal with it. It makes debugging harder. Depending on what specific flavor, it might also give the baddies a place to hide, because the signal of attacks no longer looks like the signal everyone expects.
If you can avoid *ALL* of the pitfalls. It will, without a doubt, increase the time to exploit. The problem being, if you're unable to avoid all the pitfalls of it, the negative aspects will have a much stronger cost and influence on the maintenance of the system, and the devs, contrasted with the cost it might have on any attack.
These things are always a cost/benefit calculation. Obscurity increases the cost, and it works well enough at that. It doesn't increase the cost by a lot, so it's not a super effective countermeasure, but it usually has a positive ROI because it's cheap to add.
Your complexity argument does make sense, but that also factors into the ROI calculation. I'd say obscurity is beneficial much more often than ~never.
> These things are always a cost/benefit calculation.
Yes, without a doubt! Just like all security measures. The difference being with real security measures, the security increases faster than the negative side effects. When using obscurity as a security measure, the gain is marginal at best, and even when done "perfectly" the down sides are significant.
> but it usually has a positive ROI because it's cheap to add.
My experience has always been the inverse. It is cheap to add, but more often it does nothing meaningful to the security of the system.
> I'd say obscurity is beneficial much more often than ~never.
Do you work in security? I used to think so too, back before I had to teach security fundamentals to the average software engineer.
To be clear, none of the above should be read as a refutation. I don't disagree with your opinion, per se. But in my experience, I've been frustrated many times when some non-security expert tries to add some kind of obscurity, but can't remember a single where I've thought "thank god we made this thing much more complicated". Sample bias to be sure... but if it was actually useful, I would assume I would have encountered a single time where I was glad for the added obscurity.
It's true that it's possible to increase the security of the system by adding some layers of obscurity. But not only have I've never seen it be worth the cost. The same is true about turning the system off... so when doing the cost/benefit calculation it's important to remember and account for the fact that going by history, it's never added meaningful security, and trying to work around it is almost always annoying.
I don't work in security now, but I have. I'm talking about things like changing the default SSH port from 22, not just making things complicated for the sake of it. I think this hinges on each person's past experiences, rather than the argument itself.
Saying anything about security without mentioning the nature of the threat is bad. It's also industry common practice.
Obfuscating JS is probably a decent defence against your 9 year old brother. It is not against a motivated, well funded state sponsored attacker.
Part of what bugs me about English is the practical ambiguity of the colloquial understanding of what "<foo> is <bar>" implies. Does it mean that all foos are also bars or does it mean there exists a foo where that foo is also bar? Does it mean foo is always bad or foo is often bar? Dutch is my first language and I grew up in South Viet Nam, Nigeria and Texas. I did not get the standard programming.
The author gave a few examples where compiled/minified code is public (Javascript and games) or automated vuln exploits (Wordpress example). That does explain nature of threat well enough for me.
There's a whole spectrum between 9 year old and a motivated state actor, and obfuscation is effective for a big part of the spectrum.
If the obscurity it is only an additional layer on top of a secure system, it is called "defense in depth".
It's a simple probability calculation. If some automated scanning tools can't find your service, a lot of attackers will never know of its existence. So even if it has an unpatched vulnerability, they won't attack it.
If 1000 attackers find the vulnerable system, the probability is high at least one is attacking it. If it's only or two one who find it, they might just ignore your system, because they found thousands of others they randomly chose first.
I get what this post is saying, but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding.
Obscurity provides, effectively, no security. There may be other benefits to the obscurity, but considering the obscurity a layer of your security is bad. I hope we all agree that moving telnet to another port provides no security (it's easily sniffable, easily fingerprintable).
If it provides another benefit, use it, but don't think there's any security in it.
For ~30 years I've moved my ssh to a non-standard port. It quiets down the logs nicely, people aren't always knocking on the door. But it's not a component of my security: I still disable password auth, disable root login, and only use ssh keys for access. But considering it security is undeniably bad.
> but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding.
I disagree on this. It's right up there with "premature optimization is the root of all evil" on the list of phrases that get parroted by a certain type of engineer who is more interested in repeating sound bites than understanding the situation.
You can even see it throughout this comment section: Half of the top level comments were clearly written by people who didn't even read the first section of the article and are instead arguing with the headline or what they assumed the article says
You may not see it as “security“, but any entity that is actively monitoring their logs benefits when the false positives decrease. If I am dealing with 800 failed login attempts per minute I cannot possibly investigate all of them. But if failed logins are rare in my environment, I may be able to investigate each one.
Obscurity that increases the signal to noise ratio is a force multiplier for active defense.
If port numbers were 64bit or 128bit, actually it would provide a meaningful amount of security through obscurity. Port numbers are easy to dunk on because it’s such a trivially small search space.
Similarly I've often flip-flopped on the safety of public API endpoints that are "protected" by virtue of no sitemap + UUIDs in the URL path - I think the answer ultimately is that this is fine so long as there's no way to enumerate the IDs in use?
It’s fine as a hardening measure, not as a security measure. The lack of a site map doesn’t necessarily guarantee it doesn’t leak somehow and then the question is what happens after it leaks
If you think it’s not trivial to get 64k random IP addresses to make requests for you for pennies, you are completely delusional if you think fail2ban protects a random port number in any way.
It's not "trivial", and it costs dollars, not pennies for that many attack endpoints[1]. My firewalls scale much more cost effectively, especially when I coalesce individuals into netblocks.
I don't think fail2ban protects obfuscated ports, I know it. If an IP is trying to connect to a system on port 22, it is ipso facto unwanted and doing unauthorized activities. Plonk! Onto the ban list it goes. You'd be surprised how effective that is.
Once the roar of automated skiddies is silenced, the signal of real attacks cuts through the noise quite clearly.
Remember, to avoid being eaten by most bears, you don't have to outrun them -- you only have to outrun the poor sap next to you. ;-) There is real world value in raising the bar and becoming even a moderately harder target than the rest of the crowd.
Maybe I should spin up a vanilla VM and just let it get hammered for a month and post the logs here....
[1] It's been a while since I looked at prices for tens of thousands of distinct proxy connections. Anyone want to pretend to be a hax0r and get a current price quote?
I would argue moving SSH to a non-standard port is security, but it's a different kind. By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs. So, you can detect an attack in progress or respond to an attack before it gets out of hand. With SSH on a standard port, the harmful malicious logs can blend in with the annoying malicious logs much better.
> By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs. So, you can detect an attack in progress or respond to an attack before it gets out of hand. With SSH on a standard port, the harmful malicious logs can blend in with the annoying malicious logs much better.
Advice like this should be at the top of the chapter in the textbook that teaches young sysmonkeys how to admin a box securely. Well stated.
> It quiets down the logs nicely, people aren't always knocking on the door.
Q: If you've still done the right things - "disable[d] password auth, disable[d] root login, and only use ssh keys for access" - why do you care about how 'quiet' your logs are?
Regarding Counterstrike (game) example, there were already a lot of cheaters and a cheater ecosystem that still exists to this day. I suspect Valve could address it if it wanted to, but the gameplay/development cost trade-offs aren't enough.
Valve pivoted to server-side anti-cheat and toleration because someone probably did the math on max(profit) with lootboxes.
Valve's VACnet solution is definitely interesting. It uses AI, deep learning and is server side. It's hard to tell how effective that has been for them compared to traditional client side detection systems; I don't imagine they'll share any results.
The fact that it's completely hidden from cheat developers gives them a huge advantage though. In the past, any client side algorithm or detection method could be reversed engineered by cheat developers and patched before lunch time. Now they're working against Valve completely in the dark.
Which is a the power of not relying on obscurity. The server not sending you its complete source code is not any more obscure than a secret key.
Security through obscurity is about obfuscating easy-to-recover trivia thinking it buys you any margin, like the client-side anti-cheat handing attackers everything they need to defeat it while trying to then obfuscate that code.
Security which has layers of obscurity can be incredibly powerful especially if you believe in counter intelligence. You want attackers to find the wrong key sometimes because it will lead to you collecting intelligence on them. But this increases the cost in time and infrastructure.
That isn't what the article is talking about. He is literally talking about running the JS code through an obfuscator and changing the default DB schema name. That isn't security and you know it.
Obscurity is the information you need to find the safe.
All security can eventually be broken, given enough time, this is why A very useful measure for the security of a lock is how long it takes to break. The same is true for cryptography.
Obscurity can add a buffer before you can start breaking the lock and it can act as a deterrent for opportunistic attacks. Additionally it can help with signal to noise and monitoring of the lock.
This is why you have a lock on your front door and don't tell anyone you meet where exactly in your house you store your valuable jewels (preferably out of sight). You also want to monitor anyone in your garden more closely than on the road passing by.
Everybody trying to discuss this gets the framing wrong. Obscurity isn't "bad" or "good". It's not "not" security. Security in the real-world sense is about risk. It fixes an adversary and then applies costs to them. Obscurity changes costs (usually by raising them for the adversary).
Depending on the setting and the adversary, obscurity measures can raise costs by a material or immaterial amount.
Obscurity measures usually also impose costs on defenders (and, transitively, on the intended users of the system). Those costs are different than they are for adversaries (usually: substantially lower). They might or might not be material.
Your general goal is to asymmetrically raise costs on the adversary.
Seen that way, it's usually pretty easy to reason about whether obscurity is worth pursuing or not. Don't do it if it doesn't materially raise costs for attackers, or, even if it does, if it doesn't raise costs way less for defenders and users.
What trips people up in forums like this is that we're used to dealing with security problems framed in settings where we can impose \infty costs on attackers: foreclosing all known avenues of attack (to something like a mathematical certainty, and stipulating that computer science discoveries may change the cost function tomorrow). In those settings, all obscurity measures have relatively immaterial attacker costs associated. But it's still the same underlying problem! And, in the real world, we're actually rarely operating in model situations where we really can impose \infty costs on attackers.
> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
In some ways this is not security through obscurity. If you don't have a way to enumerate tables, this is in effect another short password being added to the data. In the same way you could say that the "obscurity" of users' passwords is security through obscurity... except we still use passwords.
The idea of security through obscurity being bad stemmed from the idea that a cryptosystem should still be secure when you know how it works. That's all.
In that way, you know how WordPress works, and yet you don't have access. You know how passwords work, and yet don't have access.
Obfuscating code is interesting because it sort of sits between the two. You could execute the code, and you may know how the obfuscation scheme works, but you can't de-obfuscate easily and see the original intent, and that way it's useful. The fact that you can still execute the code does however limit the impact.
Obscurity increases the bar, and now, some actors will be prevented just by it, some delayed and some not affected at all, but after all you dont know who is attacking you and their skills!
It's just a good component of a defense in depth approach. Where it's bad is when it's the only defense. Putting a sensitive server behind port knocking will cut down on 99.99999% of random internet IPs spraying attacks at it, so it's worth doing. Just don't rely on it for the only auth check.
I want to add that Obscurity is ambiguous.
Is changing the port of SSH "obscurity"?
Some may say yes, because you could find it by bruteforce.
But a password with infinite attempts can also be bruteforced.
Here, the defining factor of security is maximum number of attempts (either on ports, username or whatever).
And the second thing that bugs me about this interaction... Sure... "Security" is a process. It is a way of looking at things. It is proper use of tools and awareness of threat when designing software.
But it is also a set of trade-offs and relationships between architectural components. It worries me that this isn't displayed in the interaction described in the post
This was largely true before. But AI reduces the cost of comprehension and finding vulnerabilities en-masse to zero, so this no longer holds, and I’m increasingly convinced that hiding in noise and complexity is no longer a valid strategy. But AI symmetrically makes it easier to secure your system so it’s not like all hope is lost even if the transition period will be brutal.
In a corporate setting my experience is that it is rarely worth it to add any obscurity on top of security. Your biggest challenge is getting peoples time and resources, and you need to use that time to implement security controls. A secondary objective you have is to build security culture over time and teach people too see patterns where more security is needed, so it is important to select what to teach to get maximum impact.
I remember when port knocking was discussed here on HN many years ago it was shit upon because people said security through obscurity is bad. What really frustrated me, at the time and still (when people shit on it), is that it's not just obscurity, it's also security. Port scans see nothing, but just knowing the port doesn't give you anything. You still need a password or key.
The problem with security through obscurity (even if it’s just an “addon”) is that it pollutes your code base, system. It’s just not worth it.
Like moving ssh to a different port. If you are the only one working on it, sure fine, as long as you remember the port. If you re working with others, then everyone needs to know the new port, so it has to be documented somehow. It’s a pita
Secret storage isn't considered "security through obscurity". Everyone knows that when you find the key to the door, you've won. Security through obscurity is more like hiding the keyhole: it isn't going to stop anyone determined, but it can be effective against someone who isn't all that motivated (well, all that motivated to target you, anyway).
Which is a poor choice of words by the industry, as this is a semantically specious argument. You are still, in the strictest sense, relying on obscurity - the key being obscure from public knowledge.
The industry should instead say: relying on an obscure process is bad when it comes to security. Better to rely on obscured data. As this is what is meant.
But technically speaking, all of information security is done through obscurity. It is all done via hiding something from being known. To state otherwise, is a misuse of semantics.
reCAPTCHA is a great success story of security through obscurity because probably less than 100 people have reverse engineered it and much less than that have produced a working solver for it that doesn't require a headless browser. Snapchat would be another good example - almost no one is going to put in the work to understand this [0]. Most companies just half ass it though and accordingly achieve nothing with the obscurity at all besides worse performance.
One thing I like about some layer of obscurity is not so much anyone directly attacking you, it's someone generically attacking you because you happened to use a common thing that someone finds a security hole with.
I am the Modern Man (Secret, secret, I've got a secret)
Who hides behind a mask (Secret, secret, I've got a secret)
So no one else can see (Secret, secret, I've got a secret)
My true identity
The way how human brain works, anything that gives you the slightly sense of "security", will make you to leave as it is without implementing an actual solution.
That security by obscurity is now a security issue.
I could see AI massively changing the calculus here. Its ability to hack and reverse-engineer (even obfuscated) artifacts may leave obscurity (read: not sharing code or binaries at all) as the primary security mechanism in the industry.
Yeah everything is open source if you’re good at reversing. Models are increasingly capable of converting binaries into source, and excellent at implementing systems when there’s a finite and constrained end state to validate against, which is exactly the profile reversing falls into.
My take: Do proper security, but if you are short on time or resources, you can start with security through obscurity, to block a few percentage of attacks, and then when you have time and resources, go ahead and add the proper security measures.
obscurity is a form of concealment, but not cover.
concealment will make specific targeting -less than straightforward,but a scorched earth obliteration will get you along with all else.
cover, is a condition that is resistant to attack when you are visible.
you should have both, resistance to sequential action when you are specificly targeted, a obfusification of presence, minimizing the frequency of targeting.
I'll push back on this: obscurity isn't a "free" layer of security, it has both security benefits and security costs.
By having obscurity you lose anther layer of security: public scrutiny. It's harder for security issues to remain if people can see them and point them out, more eyes mean more chances to catch problems.
There is also a cultural component: having to lay out what you are doing publicly means you can't just think "no one will know", and let something slide, which pushes you towards better security practices.
Of course, this doesn't mean obscurity is always going to be the worse choice, there are times it will offer more than it costs and it's particularly evident that in, for example, open source projects, a lot of the time the number of eyes on most code is low enough that "many eyes" is a bit misleading, but I think presenting it as a pure positive is wrong, obscurity has cost, even if you think it's worth it in some cases.
You're pushing back on something YOU said, not me.
I never called it a "free" layer of security, I said it was ONE layer of security. Emphasizing the one, because security comes in as many layers as one is able to manage.
Well, my issue is that "one layer" implies you can just stack it on others, especially if you say "as many layers as one is able to manage", it implies the best option is to add obscurity on top.
As my comment made the case: it's not a simple addition, it's a trade-off, and I'm saying it should be thought about in those terms. I didn't find that was evident from what you said, I guess the "push back" framing was more negative than I intended.
If the Mythos era isn't just hype marketing, "sec-scurity" might not be a valid strategy anymore. If you're taking a beat because you're small and irrelevant, you could still be massively fucked over a breach.
Mom & Pop code shops might be high risk if nation-state level vulnerability-exploitation becomes economically viable to any disgruntled prick.
Yeah, security through obscurity as part of securing a system is good. Security through obscurity as the only way of securing a system is not.
Like, a lot of it comes down to 'high friction' vs 'low friction'. Obscurity means high friction. It means that the attacker needs to craft a specific solution for your site or system in particular rather than relying on an off-the-shelf solution to handle it all for them.
For example, the article's point about changing the WordPress database prefix fits into this category perfectly. Does it really make things that much more 'secure'? No, of course not. But it does mean that automated scripts that just assume tables like wp_posts exist will fail. It means that an attacker can't just run any old WordPress hacking toolkit and watch it do its thing, they have to figure out what database prefix you're using first.
Same with antispam solutions. The best solution to stop spam is to make your site unique in some way. To add some sort of challenge that a new user has to overcome to use the site, like a question related to the topic, a honeypot field they can't fill in, a script that detects how quickly they register, etc.
This won't stop a determined spammer, but it will stop or delay bots and automated scripts that rely on the target system having the same behaviour across the board. The spammer has to specifically target your site in particular, not just every forum script running the same software.
And much of society works this way to a degree. A federated or decentralised system (whether a social network or political movement) isn't technically harder to attack than a centralised one might be.
But it is more work to attack it. If a government or company wants to censor Reddit or Discord or YouTube, they have one target they can force to censor information across the board. If they want to target the Fediverse or some sort of torrent based system, then they have to track down dozens of people and deal with at least some of those people refusing or taking it to court or being in countries that aren't under their control or whatever else.
That's kinda what a good security through obscurity setup can be. You can't mass target everyone at once, you have to target different systems individually and spend more time and resources in the process.
However, you still need real security measures there. Security through obscurity is like hiding a safe behind a painting. It'll stop casual attackers from finding it, but it won't stop a targeted attack on its own. You need a strong lock, materials that are difficult to drill through and the safe itself being difficult to remove from the wall too.
I feel like nobody actually understands the real reason security through obscurity is so bad. It results in dead cryptographers. The implementor becomes the weakest link in the chain, and entities with a tolerance for violence can fix that problem.
Cryptography is "just" a mathematically sophisticated version of manufacturing obscurity, so that's missing the point a bit. Obscurity is just information asymmetry, which is the only way we have to "secure" / anchor anything. That quote is about all the other forms of manufactured obscurity not being anywhere near as rigorous, which should be obvious.
Don’t like that you’re getting downvoted here! This is a pet peeve of mine. All security is ‘security through obscurity’ when you get right down to it.
Cryptography is just a collection of ‘obscure’ keys (and, arguably, algorithms) that someone nefarious has to guess or work out - or social engineer out of someone - to access data. They’re just really hard to guess or work out.
To me this is a major problem of everyone saying security through obscurity is bad. But then those same people reinforcing encryption as a gospel of security.
As far as I know, there are no secrets in the world. Encryption is not providing security to anything. It only gives you guarantees wrt to a certain interpretation/perspective.
Modern encryption is underpinned by, no common folk (not no one or even the people who would have the ability to which are probably the ones that should be worried about) should be able to decrypt your contents _within your lifetime_ - which in and of itself is a pragmatic goal, but does not ensure secrets remain secrets.
That isn't technically true either ;) (sorry to be pedantic!)
If your data is encrypted, what your adversary needs is some information about you - which they can gather by either buying it from someone or by investigating you - and a $10 wrench to go over there and get the keys out from you...
Most secrets are only secrets because the combination of obscurity and incentives raises the bar high enough so no one who wants to bother really bothers.
Eh, the problem with that reasoning is one of extreme degree. The "obscurity metric" would be the surprisal associated with discovering the critical piece of info. Using a random port confers brute force resistance of 2^16. At 1ms that's about a minute. Brute forcing at the same rate a 128 bit key takes like 10^28 years.
It's like hiding your key under the mat, vs hanging on a tree limb of a specific tree only you know the gps coordinate of. Both are "obscure". Huge difference in difficulty.
>For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
>My website was vulnerable. However, I was not impacted by any attacks, and I updated the plugin to a patched version a few days later. While other sites were "nulled" and destroyed, I was spared. I later found a PoC script on GitHub showcasing the exploitation. Using that PoC on my own site failed with a generic error like Table 'wordpress.wp_users' doesn't exist.
The biological sciences fully support this form of protection. One of the main benefits of the whole of sexual reproduction is based on this principle. Mutations introduce diversity to populations which allows otherwise extinction events to just affect a fraction of the population.
So yeah, maybe the university of Open Source internet considers your approach to security to be baseless, but (in addition to your empirical experience), security through obscurity is well recognized in zoology.
It's always someone outside your org telling you that obscurity is bad, and that you should definitely publish all your source code to let them see.
It's self serving outside judgment to get you to provide them value.
On the other side of the coin, there is a bias towards this trope that comes from exhibitionism: those of us who hold that security through obscurity is valuable, will usually not publish our thoughts on other security mechanisms, since we will consider that doing so decreases our security, whereas those that believe in the trope, will publish all of their thoughts on security, as they do not depend on or value the secrecy of their strategies.
Security through obscurity is only bad when it’s the only measure used. If proper security is also in place, it is the cherry on top.
For example, while I know that ssh bruteforcing bots won’t enter my server no matter how much they try, putting ssh on a non-standard port reduces the number of tries to zero.
prime number based encryption is litterally security through obscurity at scale. nature knows no other way to secure information besides hashing, physical barriers or distance or time or noise barriers.
It's useless for the example given because obfuscating JavaScript as protection no longer has any purpose, if you can let AI analyze the code, and/or in this case the API requests.
I recently did use a variation of this type of security to prevent a malicious user misusing our services... But I made a not to me an everyone else it was just a quick fix not guaranteed to work long term.
I have always replied to colleagues who poohpoohed "security through obscurity!" as if it was proof of ignorance or bad culture with "a password is just a string of obscure characters. ;-)"
That's not a serious argument, of course. But consider how the spooks operate in the field. They employ all manner of obscure practices in an attempt to improve their security. Their intentional obscurity (AFAIK) is never allowed to unnecessarily complicate operational practices, which would introduce risk. And they've probably got a lot more theory and no-BS field testing behind their practices than we do.
> There is a long-standing security recommendation to change WordPress's default database table prefix to a random one. For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
I found that just changing the default URL for the wordpress login from the usual wp-admin to anything reduces by several orders of magnitude the number of scripts that try your site for the most common vulnerabilities---something that happens constantly for any site on the web, once a minute or so.
This should be immediately intuitive to anyone who spends more than 5 minutes looking at firewall traffic of something public. 99.9% of the bots' requests aren't doing sophisticated penetration attacks, they are blasting all the low hanging fruit: the common ports, the common wordpress endpoints, the common bobby tables style sql injections and xss attacks.
Looking at logs of recently deployed web service. There is large amount of same attacks. Just sprayed all over it. So just for example adding more obscure path could slightly slow down things if the version hosted is ever exploitable. Not that it will save from more sophisticated attacks.
Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the security of your OpenSSH server, yes or no?
There's a very simple method to reduce spam in OpenSSH server logs: whitelist IPs of those who require access (could be ranges, too), and centralize over a jumphost. And something like Shodan (and friends) would find your OpenSSH server running on a different port anyway. But it wouldn't find it if you were using whitelisting of IPs of those who require access. There is, for example, no valid reason that people in China or Russia need to connect to your OpenSSH server. Why allow them to? Don't. I don't allow traffic from any IPs allocated to China or Russia, among a couple of other countries, and I don't feel like I am missing out.
Another one is port knocking. Anyone who has read access over the network between client and server can figure out the port knocking process, including a hostile actor who does a MITM (with for example a rogue WiFi AP).
So what happens is improper security (security through obscurity) means people don't apply real security measures (such as IP whitelisting). And that is why security through obscurity is bad.
As for Wordpress, the default settings and default Wordpress is quite secure these days (have been this way for at least 10 years). It is all the bells and whistles in the form of addons which are the culprit.
> Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the security of your OpenSSH server, yes or no?
If your pentester can't find your sshd on a different port: 1) that is prima facie evidence that it works for a similar (low) skill level of attacker, and 2) you should fire that pentester. I'll leave the reasoning as an exercise for the reader.
> I don't allow traffic from any IPs allocated to China or Russia, among a couple of other countries, and I don't feel like I am missing out.
Now yer talkin'! As a blanket policy, if you have no valid users outside of your own nation and no expectation that will change, why not block everybody who isn't local?
(Of course, that just means any Russians and Chinese who do manage to attack you may be actual spooks, so if that happens you're pwned anyway. ;-) But you'll have cut down on your security logs considerably.)
> Another one is port knocking. Anyone who has read access over the network between client and server can figure out the port knocking process, including a hostile actor who does a MITM (with for example a rogue WiFi AP).
While I appreciate the fact that you're thinking outside of the typical box with regard to threat modelling, such an MITM attack is quite a few orders of magnitude more intentional of an attack than the rest of the crap the average systems/security admin has to deal with. In the case of a non-targeted (ie. not against a specific user or org) you're looking at a malicious network operator, which is far more sophisticated than 99.x% of the bulk scanning and attacks most admins see. In the case of a targeted attack we're talking about funded and probably successful organized crime at the very least, and possibly even nation-state intel orgs. Only motivated, professional attackers tend to get off their butts and travel to a different location to conduct an operation like that.
Kudos for recognizing such a problem, but using that as an excuse not to employ a powerful security technology such as port knocking is rather throwing the baby out with the bathwater. If you're going to be that defeatist, just airgap the system and be done.
Now, if you are willing to go through the effort of whitelisting IPs (which, I suspect, you haven't done yet, or you'd already loathe doing it and not recommend it), the sane way of going about that is to set up a VPN and whitelist the IP of the gateway. Otherwise you've opened up an administrative can of worms that is bad indeed. Nobody wants to have to keep track of Joe Blow's home IP address, which changes weekly at least, for some whitelist.
Well, perhaps what happened was they tripwired which is realistic in a blackbox test. If you'd whitelist an IP range from a pentester, you are on greybox testing area already.
There's another reason to not allow to/from such countries: malware (e.g. phishing).
But what they do instead is use residential proxies or VPS. And I happen to live in a country where they like to rent such.
I have done whitelisting of IPs. But I have a solid ISP who notice me beforehand when my static IPv4 changes, they also provide IPv6. One admin had DHCP, so he was there whitelisted in a CIDR range (on the jumphost). Which is also why I said you need to consider to whitelist a range. When I had the same ISP in different country (Liberty Global daughter) I had a static IP because my router was (at my request) in bridge mode. What you do in PF is IP lists which can be reused (anchors), and something like OPNsense allows to configure such automatically. You can even use dynamic DNS here, having your admin update it should the need arise. Then you do not need some kind of CIDR range.
The thing with all those scanners though is: they wouldn't get in if OpenSSH ran on 22 and Wireguard on 51820. It just reduces the noise in logs.
Same thing as changing your ssh port to something random. It's a trade-off with the convenience of knowing that all of your servers are listening on port 22 and you won't need any customizations in scripts or whatnot. But there are ways to mitigate much of that.
On the benefit side, mitigating most of the computational load, log analysis load, how much are the baddies poking me while I sleep load, etc...all of these together make changing such defaults a slam dunk IMO.
Yes, echo chambers are annoying - I remember this when I challenged them by explaining to me why being superuser is problematic (hint: I countered their arguments easily, then they got very angry about this; I did this on several IRC channels back in the day, just to prove a point. I managed to get banned on one too in the process.)
But ... obscurity is NOT a security technique. It just has a catchy slogan.
The primary reason why javascript is sometimes - or often - obfuscated is to
make it harder to copy/paste and re-use stuff. That's it. Even with sanitizers, de-obfuscating it tends to increase the amount of time one has to spend to uncripple the code. This is the primary function; anything else is just decoy for the most part here.
> Security through obscurity is the practice of reducing exposure by keeping an application's inner workings or implementation details less visible to attackers
Very clearly his attempt to explain it, is already biased. Is obfuscating JavaScript security through obscurity? I mean if we can not agree to the terms, we can't agree or disagree on anything that follows.
Showing fancy images does not add any real argument to the discussion.
> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
Note that this example does not even follow his own (!!!) definition.
This has nothing to do with obscurity. It simply is another name than the
default login name. What would he expect of people to do? Retain the name? And if they change it, are ALL changes in his opinion valid to "security through obscurity"? He picked wp_8df7b8_users here. Is the name "foobar" instead a better name? Or is it "not obscure enough"?
Obscurity can be fine but it's not security. I think of it like cover and concealment in the military. Security is cover. Something you can get behind so the bullets don't hit you. Obscurity is concealment. Harder to see, harder to find, so the enemy doesn't know where to shoot, but it's not stopping any bullets. Both have advantages and disadvantages and can complement each other depending on how they're used.
Example: there are teenage gangs going around on high powered scooters in my city, carrying hammers and mini grinders. They pair up on a scooter, steal a bike and disappear.
I watched them. They don't want to hang around longer than necessary. They will only approach a bike rack that is clearly visible from the road. They will only steal a bike that has unobstructed access to the road (no tricky bollards or other bikes to get around). Even though they are full of bravado, and shout obscenities and threats at me when I tell them to fuck off, they still run away (even though the one approaching the bikes is carrying a weapon while his companion stays on the scooter ready to escape)
Anything that even mildly inconveniences these guys is enough to stop them attempting theft. The bikes they steal needs to be expensive, out in the open, with direct access to the road, and with a shitty lock. And believe it or not, those tumblers line up a lot.
Throwing a blanket over a bike is probably enough to stop them from even approaching it.
It's not great, but basically if your lock is better than the lock on the bicycle next to yours, they will most likely not steal yours..
Your bike should always looks like a less interesting target [for theft] than the other bikes in the same rack.
You only need to be faster than the slowest gazelle in the pack, right?
Gazelle bikes are pretty fast ... instructions unclear.
That's fine as long you are really clear in your mind about what's going on.
It IT there are a lot of people tossing a blanket over the scooter and believing they're affecting the ability of the the attacker when they're really changing the likelihood of an attack.
Imagine if every single person put a blanket over their bike. Now imagine if everyone got a chain that was 10 times stronger. Which world would you rather live in?
Honey pots, tar pits, bot motels, janky configs, visible telemetry (for example): these slow down adversaries in two ways. 1) They directly slow the adversary down and force them to navigate deliberately. 2) They increase uncertainty in uncomfortable ways, the effectiveness of this depends on how important it is for the adversary to remain undiscovered, not "poke the bear". Together, the effect is more than additive.
In addition to likelihood, attacks have shape. And proper installations can force your adversaries' maneuvers to take a certain shape. I've heard this referred to as terraforming.
If you're going to "do it in the road" (a highly visible bike rack), your lock or chain works much better when it is better / stronger than the herd. If everyone has a chain which is 10x stronger, then a better grinder becomes a cost of doing business. Maybe I'd rather live in a world where I didn't use that bike rack.
This is an especially good analogy because facing a well-resourced adversary in cybersecurity is like finding out that the enemy brought artillery -- hopefully you weren't relying entirely on obscurity because pretty soon there will be nowhere to hide
Funny analogy, in that when the high caliber shells start raining, most forms of cover won't make a difference. The ones that will, are not something you want to stay behind on days when you're not being actively bombed. In fact, keeping you behind such protections is by itself a military tactic - it lets the enemy roam freely and maneuver around you.
But the basic flaw of this analogy is that it implies you're at war, and your system is always in battle.
Agreed with your sentiment, and that was a great example.
Just like any security control, if it's your only means of security, it will not offer much risk reduction. Just like all security controls, the if you want risk reduction use more security controls together. Like all security controls, there is no way to eliminate risk, just reduce it as much as possible while still being able to effectively achieve your mission.
Because of this I believe security through obscurity to be important component in a healthy and mature risk posture.
It irks me when it's dismissed because obscurity is not security. No single security control is security on its own.
Obscurity by itself does provide risk reduction.
Think about leaving your bike unlocked in times square, vs. the top of a 7 000 meter mountain in the himalayas.
Which unlocked (unsecure) bike is more likely to be stolen, and ergo has a lower risk attached?
----
Obscurity does not help you when the thief has already found your bike, nor is obscurity very helpful for keeping your bike safe if you happen to live in times square.
But if you live at the top of a himalayan peak, you can be fairly certain you're not going to have your bike stolen.
the security controls for a bike on a high mountain are not obscurity, they're the lack of oxygen (that kills), the cold (that kills), the height (that kills), and the literal sheer difficulty of getting there.
you could put the bike right on the side of the mountain without any obfuscation and it won't get got because ain't no one gonna die for a bike.
its like how we know where dead people are on Everest but we can't get them down; they serve as landmarks.
I don't think that really works because obscurity isn't harder to see or find. I don't know the analogy, it's like standing out in the open and being like "yeah but who would think to look here lol".
I think you're misinterpreting "obscurity" for "lack of obscurity". If you have a vulnerability in an API interface that is completely undocumented that is a vulnerability that is obscured. It's hiding in the woods, not standing in a field.
To keep with the analogy: no one is going to stand in a field when people are shooting at you. So then why do a small subset of vocal people online suggest that you just put your bulletproof vest and claim that hiding in the woods, regardless of the vest, is a bad idea?
You know when people are shooting at you. You don't know when or if people are exploring undocumented/obscure features of your system and what they have learned about it that you were trying to hide.
Therefore, the safest assumption to make is that an adversary already has figured out all of your obscurity, because they always can do this given sufficient time and interest, at which point the only thing between them and you is your security.
That is why we design systems without obscurity and only care about security.
I agree that it's a good principle but it's taken too far when justifying needlessly growing risk surface area. Like the principle is useful to justify security hardening. It is not useful when used to increase the odds of being attacked.
Security is mandatory.
Obscurity is optional.
Obscurity is not worthwhile when it increases your own costs. Nevertheless, if you can add obscurity with negligible additional cost and inconvenience, then you should do it.
This isn't about what's a good idea or bad idea. Perhaps it's best to simply leave analogies behind, otherwise we'll just focus on the wrong thing.
Security through obscurity merely means that your system is atypical. It's not hidden, it's not secret, it's not hard to find, it's not hard to examine, it's not less visible, etc - there is nothing inherently different about the systems at all other than that one is more common than the other. It's just less typical.
What you're describing is a thing that is not obscured. Don't refer to things as obscured if they are not obscured. When others talk about about things that are obscured they are talking about things that are obscured, not things that are not obscured.
You can see my other comment on this. The word "obscure" is not very relevant to the phrase "security through obscurity".
I'm having a hard time understanding what you mean here. If something is obscured, by definition it is less visible. Being 'less typical' is a form of security because most attacks rely on some form of pattern recognition, and obscurity literally dissolves patterns into noise.
You're overly focusing on the term and not the meaning. The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often.
This notion was termed "security through obscurity" ie: "you use the less popular option, therefor that option is safer". It has nothing to do with "obscuring" in the sense of "hiding", that's a linguistic quirk of a colloquial term. If you were actually taking action to reduce the ability to understand a system in a way that you could meaningfully defend, it would no longer be "security through obscurity".
The argument has persisted because there are two different questions that sound the same (X is less typical than Y):
1. Is "X" safer than "Y"?
2. Is a user of "X" safer than a user of "Y"?
When looking at (1) in isolation, you can say things like "X lacks security features, therefor Y is safer" and "X is less often used, therefor X is safer", etc. This is a question about the posture of the project itself, in isolation.
(2) is about the context for users. The reality is that X, which perhaps is fundamentally less well built software, may actually have users who are attacked far less frequently.
Both are likely to favor "rarity is a poor indicator of safety" as we generally reject mitigation approaches that rely on attackers to behave specific ways, but what's important is that these are completely different questions and neither has to do with being obscured but rather rare.
None of this is about what is "obscured" or not. If something is obscured or obfuscated, that is a technique that can be evaluated separately by its own merits (ie: how hard is deobfuscation, how easy is it to adapt to deobfuscation, etc). All of this is about whether you're evaluating (1) or (2) - and in the case of (1), which is what the criticism always has focused on, the answer is that "rarity" is not a mitigation.
> The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often.
That is not where the term comes from.
In the infosec world, it pretty much is where the popular discourse has always been. It's just a bunch of nonsense terminology.
I understand it now, thanks
Visiblility is also a mental construct of what we expect to see and what we know already and can map to what we see. "Obscure" is doing a lot of work here. It doesn't necessarily mean hidden, it can mean the object's true purpose or form is hidden from some particular vantage, and only that vantage.
>If something is obscured, by definition it is less visible.
Obscurity is not the same thing as something being "obscured".
Obscurity means something is either difficult to comprehend, not well known or uncommon.
Obscured means something is hidden or concealed. When something is hidden, that means the thing is still there and there is a way to get to it. You can build automated tools around finding it.
>Being 'less typical' is a form of security because most attacks rely on some form of pattern recognition, and obscurity literally dissolves patterns into noise.
This is making the leap of faith assumption that "obscurity" is equivalent to "impossible to understand". In security you have no control over the attacker and therefore have to assume your attacker has more than enough knowledge and intelligence to perform the attack.
Since computer systems are static and unchanging without frequent patching, you can't assume that there is a cat and mouse game where the mouse is adapting its hiding strategies dynamically and managing to escape every single time.
Depends, some systems are dynamic. There is also a gray area where obscurity can be computationally infeasible to attack, but not bound by traditional polynomial assumptions in cryptography.
As is always the case in these semantic discussions, the answer depends on your initial axioms and assumptions, which does kind of make most of these discussions pointless (but I did learn a lot from this one).
Interesting. Have you seen the movie Braveheart? That's the leadup to the later humiliation of the king in battle, there's a movie / drama about this one too. Saw it recently, don't remember the name.
Basically the insurgents choose terrain they know well, because they live there. They choose a swamp / mire in an open field between two hills. They build fortifications. They obscure the true nature of the ground they're standing on, out in the open. They goad the king's army into finishing them then and there. They fight on foot against knights on horseback. It's a mess. They win.
The first rule of not being seen: to not stand up.
Not stand out.
Security through obscurity is mitigation basically. You reduce risk/impact, not eliminate it. There are problems - such as denial of wallet attacks - where you can only mitigate and can't eliminate the problem completely
Because I love how seriously the DoD takes newly invented terms, we have:
"The Integrated Survivability Onion"
https://cogecog.com/the-threat-onion/
1. Don't be seen.
2. Don't be acquired
3. Don't be hit
4. Don't be penetrated
5. Don't be killed
It's actually not a bad mental model training aid for teaching people who might find themselves in an active combat environment.
I feel like "Don't be captured" should be included, perhaps between 4 and 5. In cybersecurity this would be applicable to ransomware.
the implication of the "don't be acquired" and "don't be penetrated" is some sort of anti-air or anti-tank missile.
"killed" in this case would be equivalent to having something penetrate and hit sensitive systems. at that point it's basically just a function of what the penetrator is trying to do -- if they just want $$$ they ransomware. if they want exfil or DoS or making critical systems do naughty things that is also a kill.
> the implication of the "don't be acquired" and "don't be penetrated" is some sort of anti-air or anti-tank missile
not necessarily - this model is also taught for army/marines type ground combat operations, in how to effectively camouflage, how to manoeuvre.
the "don't be penetrated" is more of an equipment choice and engineering decision specific to armor and active kinetic counter-munitions systems, like anti-drone shotguns, tanks with active protection systems, chobham armor, etc.
If a munition has been fired by you, first try to not get penetrated by it at all, and if that fails, try to prevent something catastrophic like a bolus of explosive formed penetrator molten copper from spraying into the inside of your armored personnel carrier.
Works just as well anywhere, really.
The acquired concept is new to me, is this an established term?
in the sense of one military force contacting another, yes, as in acquiring a target.
Obscurity isn't security but it can support security. Until it doesn't.
I think I got the difference in my head. How about this:
Obscurity is decreasingly effective as more people use it. Security is more effective as more people use it.
Well off-topic, but did you recently listen to Andy Stumpf on a podcast?
Asking because of the Baader–Meinhof phenomenon :)
> Asking because of the Baader–Meinhof phenomenon :)
I recently learned about that and now I see it everywhere, weird.
The problem with that statement is that a lot of people who yield it fail to see the advantages that come with these extra shenanigans ; and let's just take pure concealment so I don't pushing weird arguments ; in the age of AI - each time we are able make an attacking AI misaligned we are essentially buying time ; an on-going attack is never a on-shot event ; it's an ongoing process where the attacker has to understand where it is located and what it can do ; since each element will be a resource ; do not let it have it in the first place.
It's a bit of an elitist view of security that romanticize concepts without thinking about what they can actually be used for. My personal bad experience with that was a manager who was stating me that having a different subdomain for the admin panel was a concealment and not a security practice.
I mean - it's very easy to see how this kind of argument actually prevents from doing something that can help just on the basis of philosophical purity - which often just miss the point - security is not a mechanism that will solve all your problems ; heck in fact I have to layer at least 4 mechanisms just on the http interface to feel safe ; it's more of a lot of layers that together form a barrier ;
We sit too much on TLS thinking "That's it, security job is done" - then we get some crazy stuff like French ANTS that get pawned with some IDOR ; as IF f* using some hash or something ; ANYTHING PLEASE F* HELL ; would have not helped
All modes of cyber security depend on some obscurity (e.g. password)
Ideally we want a viable plan B, for when it’s leaked/figured out. (E.g. generate new passwords)
(For convenience let’s label air-gap as kind of physical security)
> All modes of cyber security depend on some obscurity (e.g. password)
That's not what the expression means.
"Security through obscurity" has a very specific meaning — that your system's security depends on your adversary not understanding how it works. E.g. understanding RSA is a few wikipedia articles away, and that doesn't compromise its security, so RSA isn't security through obscurity.
Lucketone likely knows this and was pointing out that "obscurity" is a misleading word to use when talking about systems which all rely on obscurity, in the plain English sense of the word.
We're in a technical forum, discussing a term of art that refers to a very specific bad practice.
Lucketone's argument is essentially saying that the bad practice itself isn't actually a bad practice by equivocating the term of art and the plain language definition.
The problem is that the term of art is confusing to technical people. See TFA. Technical people make logical leaps from "avoid security through obscurity [in the specific context of security systems which depend on obscurity and for which there are better alternatives than obscurity]" to "you should never obfuscate JavaScript" because the word is imprecise.
"security through obscurity" is not a term of art; it is not solely that property which RSA does not rely upon.
No, "Security through obscurity" is a valid and useful layer. A lot of weight hangs on your word “depends” though, in which case if it is the only layer then you will eventually have, uh, problems.
I’ve used it for a long long time. Like in 1999 I’d have a knock on certain ports in a certain order to unlock the ssh port.
And lots of weird stuff to stop forum spam. Which could work for weeks or months or even a year.
Port knocking isn't security through obscurity. Given the knowledge that you have a port knocking system in place doesn't tell me what specific sequence of knocks will open up the service I want to target. Even just a two knock sequence gives you a key with 32 bits of entropy, which makes it trivial to block attempts at bruteforcing the key.
I don't see how your argument makes sense. It's all just bits of entropy in the end, be it knowing a port to connect to or a character in your key.
Yeah absolutely. That was precisely my point — Requiring a secret (be it a password or the private part of an asymmetric key) isn't security through obscurity, and finding the sequence of knocks is equivalent to finding a password of equivalent complexity.
In cryptosystems there is a difference between things that can be changed and not, eg passwords/keys are a secret that can be easily charged. Algorithms not so much.
"Security through obscurity" refers to the practice of using an hard to change "thing" as a secret, which is indeed bad practice
Not exactly.
Security through obscurity in cryptosystems would mean defining your own crypto algorithm (or using a secretly-defined one, secret in the sense that it is unknown to the adversaries) to protect your system.
It is NOT bad in itself. It IS bad if you only rely on that. Even if you'd use a "secret" algorithm, you MUST protect the keys as with a public algorithm. Also, being secret means you cannot benefit from the cryptanalysis of the community, which is in practice very important. BUT... if you have a lot of cryptanalysis expertise at disposal, then using a secret algorithm can be very effective.
i don't know a lot about the subject, but the little i know tells me this is not the way to look at this
your password (plain text) is secret because only you are supposed to a have it. in the digital realm, sharing the contents of the password (plain-text) is be akin to making a copy of it — undesirable
now, the algorithm that hashes the plain-text for comparison with the stored hash, that can be know by anyone, and typically is
so password ≠ hashing algorithm
Yes. Password and hashing algorithm are distinct things. I fully agree with you.
>Obscurity can be fine but it's not security
You literally just read how Obscurity protected OP in a cybersecurity incident. Now you are just playing word games, which are a waste of time.
It does seem to be a word game, because "it's not stopping any bullets" either isn't honest (it does stop bullets from hitting you when the enemy doesn't know where to shoot) or it's limited, just like obscurity is ("it may stop a few bullets, but it won't stop all, and there will be other weapons it can't stop either"). I think public key exchange is considered security, but it still requires to obscure your private keys.
Perhaps a better word would be resistance (to intrusion), which is a dimension orthogonal to visibility.
100%.
Obscurity alone isn't security. Security that includes obscurity in it's architecture is relevant.
I kind of wonder if the analogy might also carry over to the age of AI.
if you were hiding in cover during ww1, maybe you had a chance.
But if you were hiding from the Terminator, who is "Tireless, Fearless, Merciless", it might not last that long.
same might be said of exploits hiding from people... vs AI.
> Obscurity can be fine but it's not security.
All security is security through obscurity. When it gets obscure enough we call it “public key cryptography”. Guess the 2048-bit prime number I'm thinking of and win a fabulous prize! (access to all of my data)
> Security ONLY through obscurity is bad (Kerckhoffs's Principle).
This is the crux of the article.
(1) Kerckhoffs's Principle doesn’t say that. It says to design the system AS IF the adversary has all of the info about it except the secrets (encryption key, certificates, etc).
(2) this rule is okay if you are a solo maintainer of a WordPress installation. It’s a problem if you work at a large company and part of the company knows the full intent of this, while the rest of the company doesn’t know the other layers of security BECAUSE of the obscurity layer. In this way, it’s important to communicate that this is only a layer and shouldn’t replace any other security decisions.
Kerkhoff's principle is not about security in general, it is about the design of cryptography. Assume your opponent knows everything about how your crypto system works. Your security then lies in the keys and not knowledge of the method.
More broadly, anything that raises the cost of an attack helps security. Whether it is worth investing your defensive effort in that vs on more actual security is a different matter.
If it does not obscure your own view of the security or reasoning about the security stance.
For instance, with respect to url parameters, I have seen people being told they have an Insecure Direct Object Reference, then apply base64 encoding to it to obscure what is going on. To QA they don't notice it looks like junk, it is obscure, but base64 encoded parameters are catnip to hackers.
So in this case, the obscurity made the system worse over time.
Heck, the most cringeworthy phrase "Base64 Encryption" which I have heard many many times.
A nice point!
I love this nuance!
But I think it's covered by your immediate parent comment
> Whether it is worth investing your defensive effort in that vs on more actual security is a different matter.
So the base64 introduces a marginal security gain, but in addition to expending effort in implementation, it increases the cost of other efforts (which is the case for almost all features), in the case of a fixed cost QA (which is again, always the case), the quality of the QA (pardon the redundancy) will be the parameter that suffers.
So yes, if the security gain is very minimal, then it's likely that the cost of the feature will be so great comparatively, that it will not only affect all other parameters like ease of use, but the negative indirect impact on security will be greater than the marginal positive direct impact on security.
Many such cases.
I agree, that anything that raises the cost of an attack may be worth doing. Most “obscurity” related practices do not meaningfully raise the cost of an attack beyond a certain threshold. Physical locks are not a great analogy.
"Security through obscurity" can help in the reverse (for a time) — if they have your keys but haven’t found the locks.
Might give you enough time to change the locks. But not provably — which can matter to a lot of people.
The example in the article is more likely. Changing the name of a DB table from the default helps because any low quality probe script will break as soon as this assumption of default errors. It means that low effort, low tech, low talent attacks will fail. This is not a bad thing because these are likely to be the most common kinds of attacks.
Again, I'm not opposed to simple tricks like this to “buy some time” so long as they don’t PREVENT the deeper layers of security from being performed. But if a company has scarce resources and a choice between patching unpatched software or changing DB names from the defaults the former actually improves security and the latter should only be performed if the staff has solved all of the higher risk items.
Obscurity is not security.
But it can add a bit of delay to someone breaking actual security, so maybe they'll hit the next target first as that is a touch easier. Though with the increasing automation of hole detection and exploitation, even that might stop being the case if it hasn't already.
The biggest problem with obscurity measures IMO is psychological: people tend to assume that the measures⁰ are far more effective than they actually are, so they might make less effort to verify that the proper security is done properly.
----
[0] like moving SSHd to a non-standard port¹
[1] a solution that can inconvenience your users more than attackers, and historically (in combination with exploiting a couple of bugs) actually made certain local non-root credential scanning attacks possible if you chose a high port
Obscurity can be combined with security for much better results. Machines as well as AI in extension thrives off patterns and making illogical off-pattern decisions is usually to the benefit of the defender, not the attacker. As you said, the attacker has a wide attack surface to cover while the defender only has to fortify his home NAT. E.g. port knocking may very well throw off the hoard of scanners on the wide net simply because its not standart and the combination is known only to you. Similarly, fail2ban may not work as well on a standart SSH port, because every attacker is going to hammer that and one may get your misconfigured password root login right.
Now, in both instances, the obscurity provided does not necessarily cure your infrastructure's vulnerabilities, a dedicated attacker wouldn't have a single problem with either of these. But for someone who hammers the whole internet in a dim hope of finding another Wordpress server from 2017, or the latest flawed online security cam, your disguise is as good as perfect.
> Obscurity is not security.
So ASLR [1] is not a security control? I guess you are pretty alone with this opinion.
[1] https://en.wikipedia.org/wiki/Address_space_layout_randomiza...
No this is not what GP said, and I don't get how you reached this conclusion. This is like saying that AES is security through obscurity because it relies on key being secret. See [1] (linked in the OP) to understand the difference better.
I am pretty sure everyone who works in security agrees that obscurity is not security.
[1] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
ASLR is (still[1]) not security by obscurity.
[1] https://news.ycombinator.com/item?id=43408079
ASLR is, by definition, security by obscurity. The entire purpose of it is to make it so that it's hard to find the memory which is in use.
no because it's still possible to find the data using standard techniques, it doesn't count as obsecurity it's still possible.
I.e. just because you* don't know where something is, doesn't mean it's using obsecurity to hide.
The reason is important, because words mean things: If you say, knowledge of some secret is security though obsecurity. That means passwords are security though obsecurity.
*: that may or may not be available to the attacker.
it other words, just because a secret exists, doesn't put that secret into the 'obsecurity' category.
That's not what security through obscurity means. Security through obscurity has a specific meaning, it doesn't just mean to gain security by hiding anything it means to attempt to gain security by hiding how a system works.
ASLR is a well understood system that exploit writers know to expect and thus ASLR is not security through obscurity.
The point of ASLR is that even if you fully understand how it works, this won't make it easier to bypass the protections of ASLR, since the primary way ASLR works is through dynamic adaptation. This turns it into a probabilistic security technique where there is always a chance that an attack goes through.
Security through obscurity in this case would be to roll your own ASLR implementation with a different randomization strategy.
No, because ASLR uses a secret.
The other thing though is that there are situations where you only have a limited amount of tries for a password, and incorrect tries can have dire consequences. If you are being asked for a password by an armed guard, and you hack the system completely and get the password, but didn't know about the last obscured step that you were supposed to type it with your left hand, not your right, you will still face whatever consequences even though that step didn't add any security.
As a fan and believer of obscurity in support of security, I do not understand why
> that step didn't add any security.
It is a decision that’s part of the entire process. A branch of many in the decision tree. Other branches are deciding which characters to type for the password; ASCII characters can be as little as 1 bit apart. Deciding between left and right is also 1 bit apart.
I think it boils down to what people commonly understand to be publicly knowable information versus understood-to-be-secret information.
One example: I self-host my password manager at pw.example.com/some-secret-path/. That extra path adds as much to security as a randomly picked username in HTTP Basic Auth: arguably none. Yet, it is as impossible for attackers to enumerate and find that path as it is with passwords.
The difference is that the path leaks easier. It’s not generally understood to be a secret. Yet I argue it helps security. (Example: leaking the domain name through certificate transparency logs AND even, say, user credentials means an attack is still unsuccessful; a strictly necessary piece of the puzzle is missing).
> But it can add a bit of delay
The delay can also be infinite in practice. If a really bad zero day is discovered, it might protect you from becoming a victim. No guarantees, but it can improve your chances.
I don't think "obscurity" really buys you much (especially these days, with LLMs).
However "Not Having Stuff to Steal" works like a charm. It's thousands of years old, and has never gone out of style.
I know that it's considered blasphemy, hereabouts, but I've found that not collecting information that I don't absolutely need is pretty effective.
Even if someone knocks down all my gates and fences, they'll find the fox wasn't worth the chase.
It does make stuff like compiling metrics more of a pain, but that's my problem; not my users'.
Totally agreed, to me data is just like code: extremely valuable for the functionality it provides, but in most other ways a serious liability. That said:
> I don't think "obscurity" really buys you much (especially these days, with LLMs).
Actually I think it does so even more with LLMs. As has been posited before (particularly on the threads about open source projects going closed source) security comes down to who has paid more attention to the code, the attacker or the defender. And of course, these days attention is measured in tokens.
We know that LLM's are pretty capable of reversing-engineering to figure out an application's logic, but I would bet it takes many more tokens than reading the code or other public information directly. As such, obscurity adds an important layer to security: increasing the costs on the attacker.
Security has always been a numbers game, but now the numbers will overwhemingly be tokens and scale. If the defenders can cheaply raise the costs on the attackers by adding simple layers of obscurity, it can act as a significant deterrent at scale. I wonder if we'll even see new obfuscation techniques that are cheap to implement but targeted specifically at LLMs...
Very good point.
That's fine if the goal of breaking in is immediate theft; it might also be more along the lines of leaving something behind.
Not sure if obscurity buys you anything, then. In that case, it's all about standard security practices.
The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.
One example I remember is Pidgin storing its passwords in plain text in $HOME. They could have encrypted them with some hardcoded string, and made a lot of people happy that they would no longer grep their $HOME and find their passwords right there. However this had the side effect that now people were dropping the ball and sharing their config files with others. Or forgetting to setup proper permissions for their $HOME, etc.
In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.
Why a hardcoded string and not a user specific password the user used for pidgin? Then you’ve got real security and even using a password stored in the user’s keychain means that the passwords are not trivially accessible.
The whole point of security in depth is that you use non colinear layers of protection to raise the cost of an attack and reduce the blast radius of a successful attack.
Pidgin predates keychains, but if I remember correctly you had the option to set up a master password or to simply disable storing passwords, which were the only options that were truly incrementing security. But most users would not do that (they want autologin for a reason), so the example still applies.
(Note also most keychain implementations are not truly improving security in any way, but this is a separate topic)
> The problem with this argument is that you can justify an infinite amount of crap with it
Does that make it wrong?
If the model you're using tries to claim something that is false is actually true. Yes, your model is wrong.
Not per se. But it does make it potentially dangerous thinking depending on how it is applied.
Yes
> The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.
I almost missed the twist at the end because I had no idea what the hell cockroach papers were. I still don't understand the reference, but at least it sounds mildly interesting. So, well done.
Now, as for this strawman argument of yours about justifying an infinite amount of crap, that's true of all manner of disingenuous arguments. Who cares about that in this case?
> Or forgetting to setup proper permissions for their $HOME, etc.
This is Pidgin's fault how?
Now, if you wanted to argue that Pidgin should have put the passwords into a separate file and chmod400'ed it that would make much more sense.
> In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.
Not many good things have zero cost, do they... The point of TFA is that a little bit of well thought out obscurity pays huge dividends when applied in the real world. His example about the WP exploit ought to be all you need to read to get on board with that.
Security through obscurity is NOT bad.
Security ONLY through obscurity is bad (Kerckhoffs's Principle).
Security through obscurity, as an additional layer, is good!
I've been saying this ever since that phrase was coined. A layer or two of obscurity keeps a lot of noise out of logs, reduces alert fatigue and cuts down on storage costs especially if one is using Splunk as their SIEM and makes targeted attacks much easier to detect. I will keep it.
Couldn't agree more, I have personally benefited from the additional layer and it irks me when people outright claim it has no value.
The informed claim is not that the obscurity layer has no value. Quite the contrary, it has such a great value that it basically reduces the incentives to have great proper security and thus once the obscurity layer is breached the second line of defense is weaker.
The argument is that it's much easier to secure proper key material rather than design and config information that can often be leaked accidentally because it's actually directly manipulated by humans (employee onboarding, employee churn etc)
That's an interesting way to describe it. It's kind of like the turn away from requiring regular password updates. On paper, password rotation is good. But when you consider its interaction with human psychology, the policy makes security worse by causing people to make bad decisions.
This sounds just like my thoughts on PostgreSQL's row level security. As a additional layer it's good, as the only thing, watch out!
It would be nice if there was no overlap between terms for the operational things that help improve security (log reduction and other non-cryptographic methods of reducing admin fatigue), and the mathematical cryptographic characteristics of the system.
If the focus is on the latter, obscurity buys you nothing and adds complexity/distraction, which is bad. The former can be important though.
>I've been saying this ever since that phrase was coined
You have been alive since the 1880s?
1492 was the first time I experienced the quickening.
Smart talking your elders!
“Security through obscurity” has the connotation that it is the obscurity that achieves the security - which is bad.
”Security including obscurity“ is fine.
Yeah, I always thought that real security is priority #1. But, using convenient obscurity lowers the obvious attack surface to things like automated scanners, just a bit.
Yes it’s not that it’s bad, it just means you aren’t done yet
> Security through obscurity, as an additional layer, is good!
If and only if the security advantage it gives outweighs the the numerous disadvantages.
It never* does. That's why the comment calling it bad got so many upvotes. Mixed in with those cargoculting the meme, are people like me who have had to deal with obfuscation techniques, written by someone else, that the bad guys understood before I did.
Obfuscation as a security measure is bad, because it feels like it's positives can compete with it's negatives; but that's rarely the case.
*: effectively never
> It never* does.
Can you substantiate this claim a bit?
> Can you substantiate this claim a bit?
I might, depending on how much objective evidence you'd demand for substance. The problem with obscurity as a security feature, is the group(s) that feels the impact the most. Heuristically, you can create 3 groups that are impacted. APTs, skiddies, devs/maintainers.
Obscurity will stop skiddies... effectively 100% ....but so will everything else. Regular updates, and a half good password also stops skiddies to effectively 100%. Obscurity has a net negative effect on the system because it doesn't increase the attack cost on skiddies, but does increase the maintenance cost to engineering. This is the vast majority of attackers you'd want to deal with.
Your Advanced Persistent Threats, will be slowed by some amount of obscurity, but they will not be be stopped by it at all, at best it's a road bump. Persistence and intent will overcome any amount of obscurity. Same idea as give enough eyes, all bugs are shallow. Given enough time, any/all amount of obscurity will be understood by the baddies.
The downsides to obscurity is it's cost both to maintenance of the system as a whole, but also to the heuristics non-security developers use to find/understand bugs. Obscurity introduces significant complexity into the system. That complexity makes it harder to find and understand real bugs, but worse, it also obscures the security of the system itself to non-experts. I do believe we'll never escape the reality that most developers see obscurity, and think "this 'secret' makes this secure" but obscurity is *not* a secret. It doesn't provide additional security/safety. It only marginally increases the time to find and deploy the exploit. Here, this extra layer of obscurity actually decreases security because developers will stop looking for ways to harden the system, because this "secret" is good enough. I.e. the obscurity added only has the opportunity cost replacing the effort that would have been spent on real security.
If you have a full security team managing the obscurity the maintenance cost to the system, will be less than the cost to your APTs, but if you don't have a full time team working on it (or at least a strong expert in both how obscurity benefits the system, but more important, a strong expert in real security), the maintenance costs will exceed the time/delay until exploitation.
It's likely that I could deploy some system securely, with obscurity layered over top. But I often don't because I don't wanna deal with it. It makes debugging harder. Depending on what specific flavor, it might also give the baddies a place to hide, because the signal of attacks no longer looks like the signal everyone expects.
If you can avoid *ALL* of the pitfalls. It will, without a doubt, increase the time to exploit. The problem being, if you're unable to avoid all the pitfalls of it, the negative aspects will have a much stronger cost and influence on the maintenance of the system, and the devs, contrasted with the cost it might have on any attack.
These things are always a cost/benefit calculation. Obscurity increases the cost, and it works well enough at that. It doesn't increase the cost by a lot, so it's not a super effective countermeasure, but it usually has a positive ROI because it's cheap to add.
Your complexity argument does make sense, but that also factors into the ROI calculation. I'd say obscurity is beneficial much more often than ~never.
> These things are always a cost/benefit calculation.
Yes, without a doubt! Just like all security measures. The difference being with real security measures, the security increases faster than the negative side effects. When using obscurity as a security measure, the gain is marginal at best, and even when done "perfectly" the down sides are significant.
> but it usually has a positive ROI because it's cheap to add.
My experience has always been the inverse. It is cheap to add, but more often it does nothing meaningful to the security of the system.
> I'd say obscurity is beneficial much more often than ~never.
Do you work in security? I used to think so too, back before I had to teach security fundamentals to the average software engineer.
To be clear, none of the above should be read as a refutation. I don't disagree with your opinion, per se. But in my experience, I've been frustrated many times when some non-security expert tries to add some kind of obscurity, but can't remember a single where I've thought "thank god we made this thing much more complicated". Sample bias to be sure... but if it was actually useful, I would assume I would have encountered a single time where I was glad for the added obscurity.
It's true that it's possible to increase the security of the system by adding some layers of obscurity. But not only have I've never seen it be worth the cost. The same is true about turning the system off... so when doing the cost/benefit calculation it's important to remember and account for the fact that going by history, it's never added meaningful security, and trying to work around it is almost always annoying.
I don't work in security now, but I have. I'm talking about things like changing the default SSH port from 22, not just making things complicated for the sake of it. I think this hinges on each person's past experiences, rather than the argument itself.
Saying anything about security without mentioning the nature of the threat is bad. It's also industry common practice.
Obfuscating JS is probably a decent defence against your 9 year old brother. It is not against a motivated, well funded state sponsored attacker.
Part of what bugs me about English is the practical ambiguity of the colloquial understanding of what "<foo> is <bar>" implies. Does it mean that all foos are also bars or does it mean there exists a foo where that foo is also bar? Does it mean foo is always bad or foo is often bar? Dutch is my first language and I grew up in South Viet Nam, Nigeria and Texas. I did not get the standard programming.
The author gave a few examples where compiled/minified code is public (Javascript and games) or automated vuln exploits (Wordpress example). That does explain nature of threat well enough for me.
There's a whole spectrum between 9 year old and a motivated state actor, and obfuscation is effective for a big part of the spectrum.
I was talking about the click-baity title more than the content.
If the obscurity it is only an additional layer on top of a secure system, it is called "defense in depth".
It's a simple probability calculation. If some automated scanning tools can't find your service, a lot of attackers will never know of its existence. So even if it has an unpatched vulnerability, they won't attack it.
If 1000 attackers find the vulnerable system, the probability is high at least one is attacking it. If it's only or two one who find it, they might just ignore your system, because they found thousands of others they randomly chose first.
I get what this post is saying, but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding.
Obscurity provides, effectively, no security. There may be other benefits to the obscurity, but considering the obscurity a layer of your security is bad. I hope we all agree that moving telnet to another port provides no security (it's easily sniffable, easily fingerprintable).
If it provides another benefit, use it, but don't think there's any security in it.
For ~30 years I've moved my ssh to a non-standard port. It quiets down the logs nicely, people aren't always knocking on the door. But it's not a component of my security: I still disable password auth, disable root login, and only use ssh keys for access. But considering it security is undeniably bad.
> but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding.
I disagree on this. It's right up there with "premature optimization is the root of all evil" on the list of phrases that get parroted by a certain type of engineer who is more interested in repeating sound bites than understanding the situation.
You can even see it throughout this comment section: Half of the top level comments were clearly written by people who didn't even read the first section of the article and are instead arguing with the headline or what they assumed the article says
> But it's not a component of my security
You may not see it as “security“, but any entity that is actively monitoring their logs benefits when the false positives decrease. If I am dealing with 800 failed login attempts per minute I cannot possibly investigate all of them. But if failed logins are rare in my environment, I may be able to investigate each one.
Obscurity that increases the signal to noise ratio is a force multiplier for active defense.
If port numbers were 64bit or 128bit, actually it would provide a meaningful amount of security through obscurity. Port numbers are easy to dunk on because it’s such a trivially small search space.
Similarly I've often flip-flopped on the safety of public API endpoints that are "protected" by virtue of no sitemap + UUIDs in the URL path - I think the answer ultimately is that this is fine so long as there's no way to enumerate the IDs in use?
It’s fine as a hardening measure, not as a security measure. The lack of a site map doesn’t necessarily guarantee it doesn’t leak somehow and then the question is what happens after it leaks
But at this point, that's like saying my password is merely 'obscure.'
Good luck scanning 64k ports on a server that has a few randomly assigned fail2ban listeners.
If you think it’s not trivial to get 64k random IP addresses to make requests for you for pennies, you are completely delusional if you think fail2ban protects a random port number in any way.
It's not "trivial", and it costs dollars, not pennies for that many attack endpoints[1]. My firewalls scale much more cost effectively, especially when I coalesce individuals into netblocks.
I don't think fail2ban protects obfuscated ports, I know it. If an IP is trying to connect to a system on port 22, it is ipso facto unwanted and doing unauthorized activities. Plonk! Onto the ban list it goes. You'd be surprised how effective that is.
Once the roar of automated skiddies is silenced, the signal of real attacks cuts through the noise quite clearly.
Remember, to avoid being eaten by most bears, you don't have to outrun them -- you only have to outrun the poor sap next to you. ;-) There is real world value in raising the bar and becoming even a moderately harder target than the rest of the crowd.
Maybe I should spin up a vanilla VM and just let it get hammered for a month and post the logs here....
[1] It's been a while since I looked at prices for tens of thousands of distinct proxy connections. Anyone want to pretend to be a hax0r and get a current price quote?
I would argue moving SSH to a non-standard port is security, but it's a different kind. By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs. So, you can detect an attack in progress or respond to an attack before it gets out of hand. With SSH on a standard port, the harmful malicious logs can blend in with the annoying malicious logs much better.
> By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs.
Q: Why would you "review the logs" by (human/agent) hand for a service exposed to the Internet? What are you actually looking for?
[I say this as someone who has tens of thousands of failed auth attempts against services I expose to the Internet. Per day.]
Sounds like you are the poster child for moving ssh to a different port. :-)
If I were you I would do that immediately. Then, once your logs become actually useful again, look at them.
"Hmmm. There sure seem to be a lot of failed login attempts for bobsmith@server. Maybe I should call him up and see if there's something going on."
> By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs. So, you can detect an attack in progress or respond to an attack before it gets out of hand. With SSH on a standard port, the harmful malicious logs can blend in with the annoying malicious logs much better.
Advice like this should be at the top of the chapter in the textbook that teaches young sysmonkeys how to admin a box securely. Well stated.
> It quiets down the logs nicely, people aren't always knocking on the door.
Q: If you've still done the right things - "disable[d] password auth, disable[d] root login, and only use ssh keys for access" - why do you care about how 'quiet' your logs are?
Whatever you've done, you should keep an eye on your logs for anything suspicious. A quieter log is easier to monitor.
Regarding Counterstrike (game) example, there were already a lot of cheaters and a cheater ecosystem that still exists to this day. I suspect Valve could address it if it wanted to, but the gameplay/development cost trade-offs aren't enough.
Valve pivoted to server-side anti-cheat and toleration because someone probably did the math on max(profit) with lootboxes.
Valve's VACnet solution is definitely interesting. It uses AI, deep learning and is server side. It's hard to tell how effective that has been for them compared to traditional client side detection systems; I don't imagine they'll share any results.
The fact that it's completely hidden from cheat developers gives them a huge advantage though. In the past, any client side algorithm or detection method could be reversed engineered by cheat developers and patched before lunch time. Now they're working against Valve completely in the dark.
Which is a the power of not relying on obscurity. The server not sending you its complete source code is not any more obscure than a secret key.
Security through obscurity is about obfuscating easy-to-recover trivia thinking it buys you any margin, like the client-side anti-cheat handing attackers everything they need to defeat it while trying to then obfuscate that code.
Security which has layers of obscurity can be incredibly powerful especially if you believe in counter intelligence. You want attackers to find the wrong key sometimes because it will lead to you collecting intelligence on them. But this increases the cost in time and infrastructure.
That isn't what the article is talking about. He is literally talking about running the JS code through an obfuscator and changing the default DB schema name. That isn't security and you know it.
Security is the lock on the safe.
Obscurity is the information you need to find the safe.
All security can eventually be broken, given enough time, this is why A very useful measure for the security of a lock is how long it takes to break. The same is true for cryptography.
Obscurity can add a buffer before you can start breaking the lock and it can act as a deterrent for opportunistic attacks. Additionally it can help with signal to noise and monitoring of the lock.
This is why you have a lock on your front door and don't tell anyone you meet where exactly in your house you store your valuable jewels (preferably out of sight). You also want to monitor anyone in your garden more closely than on the road passing by.
Isn't it all just information? The lock code and the location of the safe are both just data. I think it's possible that all security is obscurity.
Everybody trying to discuss this gets the framing wrong. Obscurity isn't "bad" or "good". It's not "not" security. Security in the real-world sense is about risk. It fixes an adversary and then applies costs to them. Obscurity changes costs (usually by raising them for the adversary).
Depending on the setting and the adversary, obscurity measures can raise costs by a material or immaterial amount.
Obscurity measures usually also impose costs on defenders (and, transitively, on the intended users of the system). Those costs are different than they are for adversaries (usually: substantially lower). They might or might not be material.
Your general goal is to asymmetrically raise costs on the adversary.
Seen that way, it's usually pretty easy to reason about whether obscurity is worth pursuing or not. Don't do it if it doesn't materially raise costs for attackers, or, even if it does, if it doesn't raise costs way less for defenders and users.
What trips people up in forums like this is that we're used to dealing with security problems framed in settings where we can impose \infty costs on attackers: foreclosing all known avenues of attack (to something like a mathematical certainty, and stipulating that computer science discoveries may change the cost function tomorrow). In those settings, all obscurity measures have relatively immaterial attacker costs associated. But it's still the same underlying problem! And, in the real world, we're actually rarely operating in model situations where we really can impose \infty costs on attackers.
> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
In some ways this is not security through obscurity. If you don't have a way to enumerate tables, this is in effect another short password being added to the data. In the same way you could say that the "obscurity" of users' passwords is security through obscurity... except we still use passwords.
The idea of security through obscurity being bad stemmed from the idea that a cryptosystem should still be secure when you know how it works. That's all.
In that way, you know how WordPress works, and yet you don't have access. You know how passwords work, and yet don't have access.
Obfuscating code is interesting because it sort of sits between the two. You could execute the code, and you may know how the obfuscation scheme works, but you can't de-obfuscate easily and see the original intent, and that way it's useful. The fact that you can still execute the code does however limit the impact.
Wtf, why ppl struggle so hard with simple concept
Obscurity increases the bar, and now, some actors will be prevented just by it, some delayed and some not affected at all, but after all you dont know who is attacking you and their skills!
It's just a good component of a defense in depth approach. Where it's bad is when it's the only defense. Putting a sensitive server behind port knocking will cut down on 99.99999% of random internet IPs spraying attacks at it, so it's worth doing. Just don't rely on it for the only auth check.
I want to add that Obscurity is ambiguous. Is changing the port of SSH "obscurity"? Some may say yes, because you could find it by bruteforce. But a password with infinite attempts can also be bruteforced. Here, the defining factor of security is maximum number of attempts (either on ports, username or whatever).
Cixin Liu's Dark Forest theory is security through obscurity. If you don't have any other defense mechanism, at least try to hide.
And the second thing that bugs me about this interaction... Sure... "Security" is a process. It is a way of looking at things. It is proper use of tools and awareness of threat when designing software.
But it is also a set of trade-offs and relationships between architectural components. It worries me that this isn't displayed in the interaction described in the post
This was largely true before. But AI reduces the cost of comprehension and finding vulnerabilities en-masse to zero, so this no longer holds, and I’m increasingly convinced that hiding in noise and complexity is no longer a valid strategy. But AI symmetrically makes it easier to secure your system so it’s not like all hope is lost even if the transition period will be brutal.
I wrote a blog about this: https://tanyaverma.sh/2026/03/01/nowhere-to-hide.html
In a corporate setting my experience is that it is rarely worth it to add any obscurity on top of security. Your biggest challenge is getting peoples time and resources, and you need to use that time to implement security controls. A secondary objective you have is to build security culture over time and teach people too see patterns where more security is needed, so it is important to select what to teach to get maximum impact.
I remember when port knocking was discussed here on HN many years ago it was shit upon because people said security through obscurity is bad. What really frustrated me, at the time and still (when people shit on it), is that it's not just obscurity, it's also security. Port scans see nothing, but just knowing the port doesn't give you anything. You still need a password or key.
The problem with security through obscurity (even if it’s just an “addon”) is that it pollutes your code base, system. It’s just not worth it.
Like moving ssh to a different port. If you are the only one working on it, sure fine, as long as you remember the port. If you re working with others, then everyone needs to know the new port, so it has to be documented somehow. It’s a pita
Security through obscurity is bad. Security AND obscurity is fine. There's a very clear distinction here.
The problem with obscurity is that it breeds complacency; the implementer is often uninformed or assumes it protects everything else.
Couldn't one argue that a password is also obscurity? It's only secure until someone figures it out, just like a secret URL on a website.
Secret storage isn't considered "security through obscurity". Everyone knows that when you find the key to the door, you've won. Security through obscurity is more like hiding the keyhole: it isn't going to stop anyone determined, but it can be effective against someone who isn't all that motivated (well, all that motivated to target you, anyway).
Which is a poor choice of words by the industry, as this is a semantically specious argument. You are still, in the strictest sense, relying on obscurity - the key being obscure from public knowledge.
The industry should instead say: relying on an obscure process is bad when it comes to security. Better to rely on obscured data. As this is what is meant.
But technically speaking, all of information security is done through obscurity. It is all done via hiding something from being known. To state otherwise, is a misuse of semantics.
reCAPTCHA is a great success story of security through obscurity because probably less than 100 people have reverse engineered it and much less than that have produced a working solver for it that doesn't require a headless browser. Snapchat would be another good example - almost no one is going to put in the work to understand this [0]. Most companies just half ass it though and accordingly achieve nothing with the obscurity at all besides worse performance.
[0] https://web.archive.org/web/20201128060507/https://hot3eed.g...
One thing I like about some layer of obscurity is not so much anyone directly attacking you, it's someone generically attacking you because you happened to use a common thing that someone finds a security hole with.
It is bad!
The way how human brain works, anything that gives you the slightly sense of "security", will make you to leave as it is without implementing an actual solution.
That security by obscurity is now a security issue.
I could see AI massively changing the calculus here. Its ability to hack and reverse-engineer (even obfuscated) artifacts may leave obscurity (read: not sharing code or binaries at all) as the primary security mechanism in the industry.
Yeah everything is open source if you’re good at reversing. Models are increasingly capable of converting binaries into source, and excellent at implementing systems when there’s a finite and constrained end state to validate against, which is exactly the profile reversing falls into.
My take: Do proper security, but if you are short on time or resources, you can start with security through obscurity, to block a few percentage of attacks, and then when you have time and resources, go ahead and add the proper security measures.
When a firewall rule blocks a port, is that security or obscurity?
The AI era shows we relied on it for decades in some big software anyway despite claiming it’s bad :p ahaha
I used to joke that we had "Security through Stupidity" - everything was so half-baked that no intruder would think we were being serious.
Yeah people took a solid conceptual reminder and turned it into an absolute prohibition.
obscurity is a form of concealment, but not cover.
concealment will make specific targeting -less than straightforward,but a scorched earth obliteration will get you along with all else.
cover, is a condition that is resistant to attack when you are visible.
you should have both, resistance to sequential action when you are specificly targeted, a obfusification of presence, minimizing the frequency of targeting.
Besides fangs and claws, a substantial amount of both predators and non-predators have highly evolved camouflage.
Reducing the attack volume seems like a good idea in any case.
That's why forcing people to use E-mail addresses as user IDs is stupid.
Security through obscurity is the same thing as security through praying. A stopped clock is right twice a day.
I've been saying for years, it's one layer of security. That's undeniable.
I'll push back on this: obscurity isn't a "free" layer of security, it has both security benefits and security costs.
By having obscurity you lose anther layer of security: public scrutiny. It's harder for security issues to remain if people can see them and point them out, more eyes mean more chances to catch problems.
There is also a cultural component: having to lay out what you are doing publicly means you can't just think "no one will know", and let something slide, which pushes you towards better security practices.
Of course, this doesn't mean obscurity is always going to be the worse choice, there are times it will offer more than it costs and it's particularly evident that in, for example, open source projects, a lot of the time the number of eyes on most code is low enough that "many eyes" is a bit misleading, but I think presenting it as a pure positive is wrong, obscurity has cost, even if you think it's worth it in some cases.
You're pushing back on something YOU said, not me.
I never called it a "free" layer of security, I said it was ONE layer of security. Emphasizing the one, because security comes in as many layers as one is able to manage.
Well, my issue is that "one layer" implies you can just stack it on others, especially if you say "as many layers as one is able to manage", it implies the best option is to add obscurity on top.
As my comment made the case: it's not a simple addition, it's a trade-off, and I'm saying it should be thought about in those terms. I didn't find that was evident from what you said, I guess the "push back" framing was more negative than I intended.
I think you're overthinking this. You're probably imagining some context to this that I'm not understanding fully.
Which of your security layers isn't a trade-off?
If the Mythos era isn't just hype marketing, "sec-scurity" might not be a valid strategy anymore. If you're taking a beat because you're small and irrelevant, you could still be massively fucked over a breach.
Mom & Pop code shops might be high risk if nation-state level vulnerability-exploitation becomes economically viable to any disgruntled prick.
Security through Obscurity used to work, with AI it absolutely does not.
Yeah, security through obscurity as part of securing a system is good. Security through obscurity as the only way of securing a system is not.
Like, a lot of it comes down to 'high friction' vs 'low friction'. Obscurity means high friction. It means that the attacker needs to craft a specific solution for your site or system in particular rather than relying on an off-the-shelf solution to handle it all for them.
For example, the article's point about changing the WordPress database prefix fits into this category perfectly. Does it really make things that much more 'secure'? No, of course not. But it does mean that automated scripts that just assume tables like wp_posts exist will fail. It means that an attacker can't just run any old WordPress hacking toolkit and watch it do its thing, they have to figure out what database prefix you're using first.
Same with antispam solutions. The best solution to stop spam is to make your site unique in some way. To add some sort of challenge that a new user has to overcome to use the site, like a question related to the topic, a honeypot field they can't fill in, a script that detects how quickly they register, etc.
This won't stop a determined spammer, but it will stop or delay bots and automated scripts that rely on the target system having the same behaviour across the board. The spammer has to specifically target your site in particular, not just every forum script running the same software.
And much of society works this way to a degree. A federated or decentralised system (whether a social network or political movement) isn't technically harder to attack than a centralised one might be.
But it is more work to attack it. If a government or company wants to censor Reddit or Discord or YouTube, they have one target they can force to censor information across the board. If they want to target the Fediverse or some sort of torrent based system, then they have to track down dozens of people and deal with at least some of those people refusing or taking it to court or being in countries that aren't under their control or whatever else.
That's kinda what a good security through obscurity setup can be. You can't mass target everyone at once, you have to target different systems individually and spend more time and resources in the process.
However, you still need real security measures there. Security through obscurity is like hiding a safe behind a painting. It'll stop casual attackers from finding it, but it won't stop a targeted attack on its own. You need a strong lock, materials that are difficult to drill through and the safe itself being difficult to remove from the wall too.
You mean "concealed flaws"?
I feel like nobody actually understands the real reason security through obscurity is so bad. It results in dead cryptographers. The implementor becomes the weakest link in the chain, and entities with a tolerance for violence can fix that problem.
Cryptography is "just" a mathematically sophisticated version of manufacturing obscurity, so that's missing the point a bit. Obscurity is just information asymmetry, which is the only way we have to "secure" / anchor anything. That quote is about all the other forms of manufactured obscurity not being anywhere near as rigorous, which should be obvious.
Don’t like that you’re getting downvoted here! This is a pet peeve of mine. All security is ‘security through obscurity’ when you get right down to it.
Cryptography is just a collection of ‘obscure’ keys (and, arguably, algorithms) that someone nefarious has to guess or work out - or social engineer out of someone - to access data. They’re just really hard to guess or work out.
Pet peeve of mine as well.
To me this is a major problem of everyone saying security through obscurity is bad. But then those same people reinforcing encryption as a gospel of security.
As far as I know, there are no secrets in the world. Encryption is not providing security to anything. It only gives you guarantees wrt to a certain interpretation/perspective.
Modern encryption is underpinned by, no common folk (not no one or even the people who would have the ability to which are probably the ones that should be worried about) should be able to decrypt your contents _within your lifetime_ - which in and of itself is a pragmatic goal, but does not ensure secrets remain secrets.
That isn't technically true either ;) (sorry to be pedantic!)
If your data is encrypted, what your adversary needs is some information about you - which they can gather by either buying it from someone or by investigating you - and a $10 wrench to go over there and get the keys out from you...
Most secrets are only secrets because the combination of obscurity and incentives raises the bar high enough so no one who wants to bother really bothers.
Eh, the problem with that reasoning is one of extreme degree. The "obscurity metric" would be the surprisal associated with discovering the critical piece of info. Using a random port confers brute force resistance of 2^16. At 1ms that's about a minute. Brute forcing at the same rate a 128 bit key takes like 10^28 years.
It's like hiding your key under the mat, vs hanging on a tree limb of a specific tree only you know the gps coordinate of. Both are "obscure". Huge difference in difficulty.
>For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
>My website was vulnerable. However, I was not impacted by any attacks, and I updated the plugin to a patched version a few days later. While other sites were "nulled" and destroyed, I was spared. I later found a PoC script on GitHub showcasing the exploitation. Using that PoC on my own site failed with a generic error like Table 'wordpress.wp_users' doesn't exist.
The biological sciences fully support this form of protection. One of the main benefits of the whole of sexual reproduction is based on this principle. Mutations introduce diversity to populations which allows otherwise extinction events to just affect a fraction of the population.
So yeah, maybe the university of Open Source internet considers your approach to security to be baseless, but (in addition to your empirical experience), security through obscurity is well recognized in zoology.
The source of this bias is voyeurism.
It's always someone outside your org telling you that obscurity is bad, and that you should definitely publish all your source code to let them see.
It's self serving outside judgment to get you to provide them value.
On the other side of the coin, there is a bias towards this trope that comes from exhibitionism: those of us who hold that security through obscurity is valuable, will usually not publish our thoughts on other security mechanisms, since we will consider that doing so decreases our security, whereas those that believe in the trope, will publish all of their thoughts on security, as they do not depend on or value the secrecy of their strategies.
Security through obscurity is only bad when it’s the only measure used. If proper security is also in place, it is the cherry on top.
For example, while I know that ssh bruteforcing bots won’t enter my server no matter how much they try, putting ssh on a non-standard port reduces the number of tries to zero.
Kerchkoff would beg to disagree. Please do not refuse a beggar: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
Outch! Security is security. Obscurity is obscurity. Piety is piety. All three have nothing in common.
prime number based encryption is litterally security through obscurity at scale. nature knows no other way to secure information besides hashing, physical barriers or distance or time or noise barriers.
Obscurity should always be part of security
Just because you have a bunker, doesn’t mean you hand the enemy the plans.
This presumes you have a working bunker and not a flawed one because you obscured the details from good actors that could identify problems.
It's useless for the example given because obfuscating JavaScript as protection no longer has any purpose, if you can let AI analyze the code, and/or in this case the API requests.
I recently did use a variation of this type of security to prevent a malicious user misusing our services... But I made a not to me an everyone else it was just a quick fix not guaranteed to work long term.
I have always replied to colleagues who poohpoohed "security through obscurity!" as if it was proof of ignorance or bad culture with "a password is just a string of obscure characters. ;-)"
That's not a serious argument, of course. But consider how the spooks operate in the field. They employ all manner of obscure practices in an attempt to improve their security. Their intentional obscurity (AFAIK) is never allowed to unnecessarily complicate operational practices, which would introduce risk. And they've probably got a lot more theory and no-BS field testing behind their practices than we do.
Maybe we should ask them for advice?
... perfect topic for Hacker news ...
Wordpress is a great example. He cites
> There is a long-standing security recommendation to change WordPress's default database table prefix to a random one. For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
I found that just changing the default URL for the wordpress login from the usual wp-admin to anything reduces by several orders of magnitude the number of scripts that try your site for the most common vulnerabilities---something that happens constantly for any site on the web, once a minute or so.
This should be immediately intuitive to anyone who spends more than 5 minutes looking at firewall traffic of something public. 99.9% of the bots' requests aren't doing sophisticated penetration attacks, they are blasting all the low hanging fruit: the common ports, the common wordpress endpoints, the common bobby tables style sql injections and xss attacks.
Looking at logs of recently deployed web service. There is large amount of same attacks. Just sprayed all over it. So just for example adding more obscure path could slightly slow down things if the version hosted is ever exploitable. Not that it will save from more sophisticated attacks.
Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the security of your OpenSSH server, yes or no?
There's a very simple method to reduce spam in OpenSSH server logs: whitelist IPs of those who require access (could be ranges, too), and centralize over a jumphost. And something like Shodan (and friends) would find your OpenSSH server running on a different port anyway. But it wouldn't find it if you were using whitelisting of IPs of those who require access. There is, for example, no valid reason that people in China or Russia need to connect to your OpenSSH server. Why allow them to? Don't. I don't allow traffic from any IPs allocated to China or Russia, among a couple of other countries, and I don't feel like I am missing out.
Another one is port knocking. Anyone who has read access over the network between client and server can figure out the port knocking process, including a hostile actor who does a MITM (with for example a rogue WiFi AP).
So what happens is improper security (security through obscurity) means people don't apply real security measures (such as IP whitelisting). And that is why security through obscurity is bad.
As for Wordpress, the default settings and default Wordpress is quite secure these days (have been this way for at least 10 years). It is all the bells and whistles in the form of addons which are the culprit.
> Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the security of your OpenSSH server, yes or no?
If your pentester can't find your sshd on a different port: 1) that is prima facie evidence that it works for a similar (low) skill level of attacker, and 2) you should fire that pentester. I'll leave the reasoning as an exercise for the reader.
> I don't allow traffic from any IPs allocated to China or Russia, among a couple of other countries, and I don't feel like I am missing out.
Now yer talkin'! As a blanket policy, if you have no valid users outside of your own nation and no expectation that will change, why not block everybody who isn't local?
(Of course, that just means any Russians and Chinese who do manage to attack you may be actual spooks, so if that happens you're pwned anyway. ;-) But you'll have cut down on your security logs considerably.)
> Another one is port knocking. Anyone who has read access over the network between client and server can figure out the port knocking process, including a hostile actor who does a MITM (with for example a rogue WiFi AP).
While I appreciate the fact that you're thinking outside of the typical box with regard to threat modelling, such an MITM attack is quite a few orders of magnitude more intentional of an attack than the rest of the crap the average systems/security admin has to deal with. In the case of a non-targeted (ie. not against a specific user or org) you're looking at a malicious network operator, which is far more sophisticated than 99.x% of the bulk scanning and attacks most admins see. In the case of a targeted attack we're talking about funded and probably successful organized crime at the very least, and possibly even nation-state intel orgs. Only motivated, professional attackers tend to get off their butts and travel to a different location to conduct an operation like that.
Kudos for recognizing such a problem, but using that as an excuse not to employ a powerful security technology such as port knocking is rather throwing the baby out with the bathwater. If you're going to be that defeatist, just airgap the system and be done.
Now, if you are willing to go through the effort of whitelisting IPs (which, I suspect, you haven't done yet, or you'd already loathe doing it and not recommend it), the sane way of going about that is to set up a VPN and whitelist the IP of the gateway. Otherwise you've opened up an administrative can of worms that is bad indeed. Nobody wants to have to keep track of Joe Blow's home IP address, which changes weekly at least, for some whitelist.
Well, perhaps what happened was they tripwired which is realistic in a blackbox test. If you'd whitelist an IP range from a pentester, you are on greybox testing area already.
There's another reason to not allow to/from such countries: malware (e.g. phishing).
But what they do instead is use residential proxies or VPS. And I happen to live in a country where they like to rent such.
I have done whitelisting of IPs. But I have a solid ISP who notice me beforehand when my static IPv4 changes, they also provide IPv6. One admin had DHCP, so he was there whitelisted in a CIDR range (on the jumphost). Which is also why I said you need to consider to whitelist a range. When I had the same ISP in different country (Liberty Global daughter) I had a static IP because my router was (at my request) in bridge mode. What you do in PF is IP lists which can be reused (anchors), and something like OPNsense allows to configure such automatically. You can even use dynamic DNS here, having your admin update it should the need arise. Then you do not need some kind of CIDR range.
The thing with all those scanners though is: they wouldn't get in if OpenSSH ran on 22 and Wireguard on 51820. It just reduces the noise in logs.
Nice. If you do the opposite of what WordPress does for security you're probably on the right track.
Same thing as changing your ssh port to something random. It's a trade-off with the convenience of knowing that all of your servers are listening on port 22 and you won't need any customizations in scripts or whatnot. But there are ways to mitigate much of that.
On the benefit side, mitigating most of the computational load, log analysis load, how much are the baddies poking me while I sleep load, etc...all of these together make changing such defaults a slam dunk IMO.
Mo Beigi unfortunately misses the point.
Yes, echo chambers are annoying - I remember this when I challenged them by explaining to me why being superuser is problematic (hint: I countered their arguments easily, then they got very angry about this; I did this on several IRC channels back in the day, just to prove a point. I managed to get banned on one too in the process.)
But ... obscurity is NOT a security technique. It just has a catchy slogan.
The primary reason why javascript is sometimes - or often - obfuscated is to make it harder to copy/paste and re-use stuff. That's it. Even with sanitizers, de-obfuscating it tends to increase the amount of time one has to spend to uncripple the code. This is the primary function; anything else is just decoy for the most part here.
> Security through obscurity is the practice of reducing exposure by keeping an application's inner workings or implementation details less visible to attackers
Very clearly his attempt to explain it, is already biased. Is obfuscating JavaScript security through obscurity? I mean if we can not agree to the terms, we can't agree or disagree on anything that follows.
Showing fancy images does not add any real argument to the discussion.
> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
Note that this example does not even follow his own (!!!) definition.
This has nothing to do with obscurity. It simply is another name than the default login name. What would he expect of people to do? Retain the name? And if they change it, are ALL changes in his opinion valid to "security through obscurity"? He picked wp_8df7b8_users here. Is the name "foobar" instead a better name? Or is it "not obscure enough"?