Comment by astura | Hacker News Reader

Comment by astura | Hacker News Reader

Yes... This is well known and not actually at all controversial. The only people who are against adding an additional layer of security are the ones who don't actually understand the concept, they only heard "security through obscurity is bad." Those people shouldn't be securing systems.

For example shutting up chatty webservers is a good and well established security practice (stuff like removing x-powered-by response headers)[1]. This is one of the security policies of the government systems I work on. but... it's security through obscurity, however, it's far from the only practice a website used to keep itself secure.

I don't know if its true but I also heard that the NSA doesn't publish some of their physical addresses and the highway exit are unmarked - that's security through obscurity. Again, that doesn't mean they go ahead and leave the doors unlocked.

Another recommended security practice, don't use usernames like 'root,' 'admin,' etc.

In meatspace there's the advice of "don't leave valuables in your car in plain sight," that's uncontroversial but its also security through obscurity, covering up your iPad when you leave it in the car doesn't mean you don't lock your door.

But, the prerequisite is really, actually understanding security, as a concept, including understanding tradeoffs. Without a good understanding you aren't ever going to succeed in securing any systems.

[1] https://www.troyhunt.com/shhh-dont-let-your-response-headers...

This should be uncontroversial. Anything that increases the amount of work needed to carry out a successful attack increases its security. The only concern is whether you end up being overall less secure because of a misplaced trust in the obscurity layer.

But obscuring may take away time from securing and it adds complexity to the system but systems with less complexity are easier to secure. So you at least have to be careful.

"But obscuring may take away time from securing"

That's because you're looking at the order entirely wrong - you secure then obscure.

It is also important to consider the complexity too.

There is no such thing as "Security through unnecessary complexity", only the opposite.

The examples about changing port numbers are great, they are simple configuration changes, when people start wanting to add obscurity "features" they often wander down the path of complexity, inevitably adding vulnerabilities.

> you secure then obscure

pillage THEN burn

Going back to what I said, if you actually fully understand the concept, you wouldn't misplace your trust in the obscure layer. If you don't understand the basic concepts its game over, you have already failed.

Most attackers usually just go for the lowest of the low hanging fruit. Obscuring systems from them is not a bad thing.

> Anything that increases the amount of work needed to carry out a successful attack increases its security.

By this logic, any system which is more obscure is more secure. So for example, a 20 year old Sun server running telnet and has never been patched is more secure than a brand new server, because you might have to learn SPARC assembly or sniff the traffic/create a telnet parser. If you're trying to argue that added complexity equals security, that makes even less sense.

> Anything that increases the amount of work needed to carry out a successful attack increases its security.

Jesus christ this is a stupid statement.

Of course, if you use a tool in a stupid fashion, you get stupid results. In physical security terms, security is measured in the amount of time it would take for an attacker to penetrate the defense. This also works in terms of computer security. I'd carefully choose a bit of obscurity which would force an attacker to improvise on the fly, while under time constraint or working against a chance of discovery.

A good analogy would be a moat around a castle. A moat can be nothing more than an empty ditch. Just having an empty ditch surrounding a building would make for a rotten castle. However, having such a ditch just outside the walls interferes with the deployment of siege engines and ladders in exactly the place where one has to worry most about counterattack and so is worthwhile.

So in one sense, you are correct. You don't just put anything up without thinking about cost/benefit. Costs might be in the form of increased attack surface, or increased operating costs. The cost might even be in the form of reduced overall security.

So for example, a 20 year old Sun server running telnet and has never been patched is more secure than a brand new server

If looking up the old exploits is easier than finding the zero-days on the new server, then this is less obscure by definition. It's a badly thought out straw man.

Why don't I just put six different proxies in front of my webserver? That's six times the effort at least. Dang that must be secure.

Going back to cost/benefit, if the 6 proxies spoil your operating costs and latency, then it probably doesn't work out.

When I say work I meant more in the computational sense (although wall clock time also counts). If port numbers were on a 32 bit address space, using a random port for your service instead of the standard one would be a strong security benefit, precisely because of the amount of "work" needed to cross that barrier.

But no, there's no good way to justify using an outdated system because of the obscurity factor. It's the asymmetry of work that obscurity offers that provides the benefit. If you're making your own life miserable in the process you're doing it wrong.

"Security through obscurity is bad" because most companies that employ it tend to think that's enough.

This is similar to "don't roll your own crypto", which doesn't actually apply to everyone, but it's meant to stop the majority from screwing up in case they decided to do just that.

Agreed. It very very rapidly becomes a crutch. Seen it a zillion times. By forcing transparency you force developers to write good code. You also get more eyes on the problem.

We have to deal differentiate obscurity versus runtime information leaking.

Security by obscurity is like a moat around a castle. A moat makes assaulting castle walls harder. However, no one who could afford something better would propose to make a castle by putting a ditch around a house. (There were some early castles that were like this, but they became obsolete.)

> the highway exit are unmarked

I'm sure that they also have clandestine locations, but:

https://www.google.com/search?tbm=isch&q=nsa+freeway+exit

I said "some of their physical addresses," not "every one of their physical addresses" and I prefaced it with "I don't know if its true but I heard."

I didn't mean to suggest that what you heard was wrong in general -- just the part about the highway exit in particular.

You didn't even suggest that:

OP is claiming some locations are hidden, not their main office.

The main office is well marked giant office complex next to the public cryptographic museum.

You also made note of the highway being unmarked, which is a demonstrable lie. This is a typical NSA redirection tactic. In fact it's one of the first tactics taught (my former USMC and CIA grandfather taught me well.)

I think you better come up with a far better rationalization than what you're currently proposing.

It should be uncontroversial but I don't think it is.

Probably because there is no war, probably because camouflage on an M1 tank is somehow more valuable than changing ssh from 22 to 24, probably because this so called field of computer security is just more pop-culture.

I don't think I follow.

The concept seems valid, but the obscurity term should apply to the implementer, not the attacker. i.e. if you as the system designer don't understand how it all works under the covers then it's definitely a problem, but if the attacker doesn't, then it's good practice, because it adds another hurdle to clear.

The NSA exit actually is marked. Going down it if you're not authorized to do so might get you shot.

https://mobile.nytimes.com/2015/03/31/us/nsa-maryland-gate.h...

Going down one, refusing to follow instructions, and speeding towards a police car.. might get you shot.

... while driving a stolen car.

Reply on news.ycombinator.com