Get the top HN stories in your inbox every day.
rascul
raffraffraff
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.
canpan
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..
WhyNotHugo
Your bike should always looks like a less interesting target [for theft] than the other bikes in the same rack.
kombookcha
You only need to be faster than the slowest gazelle in the pack, right?
mday27
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
TeMPOraL
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.
cindyllm
[dead]
neoCrimeLabs
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.
Maxion
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.
staticassertion
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".
willis936
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?
arcfour
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.
staticassertion
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.
Byamarro
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
pamcake
Obscurity isn't security but it can support security. Until it doesn't.
6r17
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
thephyber
> 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.
MattPalmer1086
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.
rileymat2
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.
TZubiri
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.
MattPalmer1086
A nice point!
catlifeonmars
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.
sroussey
"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.
thephyber
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.
ChrisMarshallNY
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'.
keeda
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...
ChrisMarshallNY
Very good point.
danparsonson
That's fine if the goal of breaking in is immediate theft; it might also be more along the lines of leaving something behind.
ChrisMarshallNY
Not sure if obscurity buys you anything, then. In that case, it's all about standard security practices.
dspillett
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
kbrkbr
> 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...
msm_
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.
undefined
minitech
ASLR is (still[1]) not security by obscurity.
bigstrat2003
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.
staticassertion
No, because ASLR uses a secret.
undefined
titularcomment
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.
NewsaHackO
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.
diarrhea
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).
undefined
andix
> 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.
AshamedCaptain
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.
vlovich123
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.
AshamedCaptain
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)
2OEH8eoCRo0
> The problem with this argument is that you can justify an infinite amount of crap with it
Does that make it wrong?
dspillett
Not per se. But it does make it potentially dangerous thinking depending on how it is applied.
HeavyStorm
Yes
i_think_so
> 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.
trashb
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.
allknowingfrog
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.
Bender
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.
mobeigi
Couldn't agree more, I have personally benefited from the additional layer and it irks me when people outright claim it has no value.
ithkuil
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)
kstrauser
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.
rcleveng
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!
bee_rider
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.
OhMeadhbh
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.
srdjanr
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.
OhMeadhbh
I was talking about the click-baity title more than the content.
catoc
“Security through obscurity” has the connotation that it is the obscurity that achieves the security - which is bad.
”Security including obscurity“ is fine.
consumer451
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.
justonceokay
Yes it’s not that it’s bad, it just means you aren’t done yet
andix
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.
linsomniac
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.
Aurornis
> 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
elevation
> 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.
vlovich123
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.
sudb
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?
vlovich123
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
gavmor
But at this point, that's like saying my password is merely 'obscure.'
i_think_so
Good luck scanning 64k ports on a server that has a few randomly assigned fail2ban listeners.
vlovich123
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.
undefined
spacemule
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.
logifail
> 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.]
i_think_so
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."
i_think_so
> 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.
logifail
> 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?
rcxdude
Whatever you've done, you should keep an eye on your logs for anything suspicious. A quieter log is easier to monitor.
blamestross
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.
Get the top HN stories in your inbox every day.
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.