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.
Security through obscurity is not bad
41–50 of 228 posts
Re: Security through obscurity is not bad
#42I 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 f…
> 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.
Re: Security through obscurity is not bad
#43Just because you have a bunker, doesn’t mean you hand the enemy the plans.
Re: Security through obscurity is not bad
#44I 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 f…
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?
Re: Security through obscurity is not bad
#45I 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 f…
> 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
Re: Security through obscurity is not bad
#46The 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 thei…
> The problem with this argument is that you can justify an infinite amount of crap with it Does that make it wrong?
Yes
Re: Security through obscurity is not bad
#47I 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 f…
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.
Re: Security through obscurity is not bad
#48Security 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.
[dead]
Re: Security through obscurity is not bad
#49The 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 thei…
> 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.
Re: Security through obscurity is not bad
#50Earlier quoted context omitted.
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