[grayhatter]

> 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

[stavros]

> It never* does.

Can you substantiate this claim a bit?

[grayhatter]

> 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.

[stavros]

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.

[grayhatter]

> 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.

[stavros]

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.