Live data from Hacker News

Security by obscurity is underrated

utkusen.com

31–40 of 530 posts

Re: Security by obscurity is underrated

#31
I was thinking maybe this goes back to people in security looking at things in a different way than others? Like ITSec folks spend all day everyday reading about every possible way a bad actor can make bad things happen. They look at something like changing the port SSH listens on and think about all the ways the best & brightest bad actors will get around that in no time at all. Everything ends up looking pretty useless at some point, because you end up seeing that it's possible to get around nearly everything.

Another example might be folks in the security community saying that SMS 2fa is no good because all it takes is someone taking over your phone account to get around. Sure, that happens, but not all that often, and usually happens to people with something that's worth time & focus by talented bad actors.

"Security by obscurity is not enough by itself. You should always enforce the best practices. However, if you can reduce the risk with zero cost, you should do that. Obscurity is a good layer of security."

I rather like the conclusion.

Re: Security by obscurity is underrated

#32
This came up in the stackoverflow podcast where Reddit founders were the guest. They mentioned that they stored plain text passwords initially which is fundamentally a bad design but at the same time it helps to block spam. If a user starts to create a lot of accounts programmatically they generally use the same password thus much easier to filter. Security via Obscurity, if you can do it, can be very very effective.

Re: Security by obscurity is underrated

#33
So the "developer" who created an "educational" ransomware project that was abused for half a decade by criminal groups now has a controversial and low-level view of security practices and is broadcasting it to the world. I'm shocked, I tell you. Shocked!

Re: Security by obscurity is underrated

#34
post #29

To me this seems like a bit of a strawman argument. The claim was never that using obscurity is bad and should be avoided. As I first heard it, "Security through obscurity is not security" is saying that if you are relying on obscurity to keep your stuff secure then you aren't doing enough. I think this is still true and the conclusion of the article agrees Security by obscurity is not enough by itself. You should al…

I agree. Obscurity is a weak strategy. If you can make obscurity not necessary you will gain far better results.

Re: Security by obscurity is underrated

#35
post #3

Like the article. Security also needs to be sensitive to usability trade-offs. Make things hard for adversaries, easy for intended users. For some things, like VPNs, the adversaries are going to be more familiar with the details than the intended users. I often joke that an effective way to crack a VPN would be offer to configure it properly for a user in exchange for ten minutes of unfettered access to the target co…

This is the whole "shadow IT" that actually results in a lot of security breaches. Look at the recent twitter hack for a great example. Staff were storing login credentials in a slack pinned message because using the right tools were a headache.

One thing I despise is internal systems with self signed certs because setting it up properly is a faff or no one can agree on the latest and greatest way to do it.

Oh cool that’s fine I’ll just click away all the big scary warnings in my browser to access this page. I’m an engineer and know what I’m doing! It’s a super strong key anyway. Oh wait I’ll just send this link to Bob in accounting and tell him to do the very thing we’ve been telling users not to do under pain of ridicule for ages and then he’s now doing that 10 times a day and now all of https is pointless because he knows that ‘it’s probably fine to ignore it because I have to do that at work’...

Re: Security by obscurity is underrated

#36
post #23

>However, if you can reduce the risk with zero cost, you should do that. Zero cost is rarely, rarely true with regards to operations. If you use non-standard ports, you'll have to document that somewhere, or else it becomes tribal knowledge. If you don't document it, and someone leaves, how do you know how to access your servers? At the very moment you don't know how to SSH in, you've just paid the price. It's no lon…

Zero net cost is certainly almost never a thing; but zero incremental cost is often a thing.

To further your alternate-port example: let's say you have some instances running on Google Cloud. GCP already has a big CLI codebase that they get everybody to use, which has a command `gcloud compute ssh` for connecting to instances, which already has tons of magic built into it. It would therefore be pretty easy for GCP to add additional magic — e.g. randomizing the SSH ports of newly-deployed instances, and then publishing those ports as project secrets in a way that the gcloud CLI tool can discover and use in the `gcloud compute ssh` subcommand.

The incremental cost of an approach like this is effectively zero: the DevOps folks didn’t have to build anything new to get this advantage, because they already built all the infrastructure required (i.e. spent the labor-cost you’d be spending) in the process of getting some other, earlier advantages.

In a sense, setting up a platform or infrastructure that's more complex/flexible than what you require at the time, is the opposite of "technical debt." Rather than saving labor now but needing to be paid down with later labor, it requires more labor now, but potentially saves labor later. It’s a bit like paying a retainer fee: you get less than you pay for (or nothing) up front; but in return, you get things "for free" later on. "Tech equity" might be a good term for this — it's what you get when you invest labor into your tech stack.

Re: Security by obscurity is underrated

#37
post #27

There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…

The cost of not having SSH vulnerabilities is infinite because there is no way to ensure that.

Re: Security by obscurity is underrated

#38

Agree with the article. People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally meant as "if your only security is obscurity, it's bad". Many serious real-world scenarios do use obscurity as an additional layer. If only because sometimes, you know that a dedicated attacker will be able to breach, what you are looking for is to delay them…

An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers) while being a small deterrent against unauthorised users (as they will be able to circumvent the "obscurity layer" and replicate their method to other bad actors).

edit: In the first sentence "against" is not what I wanted to say: what I wanted to say is that it "downgrades it's effectiveness". I agree that obscurity can and sometimes should be a layer of security.

Re: Security by obscurity is underrated

#39
Obscurity is double sided. While the attacker can be hindered by it, so is someone who can audit the defense and find its deficiencies. I always thought that was the main argument for avoiding security by obscurity - the benefit of better audit and improving defense overall outweighs the benefit of obscuring it.

Re: Security by obscurity is underrated

#40

Please do not use random variable names in source code. Uglify/minify instead. It’s a bit unclear because right above that “tip” is obfuscating code, did I miss something?

For JS, does it not make sense to use random variable names in production? Obviously you don't want to while developing, but it seems like an efficient method to help obfuscate.

Yeah, GP is saying you as the developer should not use random variable names. Let an uglifier select random names for you.
Post reply on HN