Live data from Hacker News

Security through obscurity is not bad

mobeigi.com

221–228 of 228 posts

Re: Security through obscurity is not bad

#221
post #203

Earlier quoted context omitted.

Because I love how seriously the DoD takes newly invented terms, we have: "The Integrated Survivability Onion" https://cogecog.com/the-threat-onion/ 1. Don't be seen. 2. Don't be acquired 3. Don't be hit 4. Don't be penetrated 5. Don't be killed It's actually not a bad mental model training aid for teaching people who might find themselves in an active combat environment.

I feel like "Don't be captured" should be included, perhaps between 4 and 5. In cybersecurity this would be applicable to ransomware.

the implication of the "don't be acquired" and "don't be penetrated" is some sort of anti-air or anti-tank missile.

"killed" in this case would be equivalent to having something penetrate and hit sensitive systems. at that point it's basically just a function of what the penetrator is trying to do -- if they just want $$$ they ransomware. if they want exfil or DoS or making critical systems do naughty things that is also a kill.

Re: Security through obscurity is not bad

#222

Earlier quoted context omitted.

> 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 g…

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.

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

Re: Security through obscurity is not bad

#223

Earlier quoted context omitted.

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.

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

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.

Re: Security through obscurity is not bad

#224
post #203

Earlier quoted context omitted.

I feel like "Don't be captured" should be included, perhaps between 4 and 5. In cybersecurity this would be applicable to ransomware.

the implication of the "don't be acquired" and "don't be penetrated" is some sort of anti-air or anti-tank missile. "killed" in this case would be equivalent to having something penetrate and hit sensitive systems. at that point it's basically just a function of what the penetrator is trying to do -- if they just want $$$ they ransomware. if they want exfil or DoS or making critical systems do naughty things that is…

> the implication of the "don't be acquired" and "don't be penetrated" is some sort of anti-air or anti-tank missile

not necessarily - this model is also taught for army/marines type ground combat operations, in how to effectively camouflage, how to manoeuvre.

the "don't be penetrated" is more of an equipment choice and engineering decision specific to armor and active kinetic counter-munitions systems, like anti-drone shotguns, tanks with active protection systems, chobham armor, etc.

If a munition has been fired by you, first try to not get penetrated by it at all, and if that fails, try to prevent something catastrophic like a bolus of explosive formed penetrator molten copper from spraying into the inside of your armored personnel carrier.

Re: Security through obscurity is not bad

#225

Earlier quoted context omitted.

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.

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 top…

For the full reasoning see this page https://developer.pidgin.im/wiki/PlainTextPasswords which is now back online. It was accidentally broken in a recent server migration.

That said, purple3/pidgin3 (still in development) only supports for keyrings and doesn't try to do any password management on its own even though password managers fall into the "Store a password(s) behind a password" as detailed on the above page.

Re: Security through obscurity is not bad

#226
post #111

Earlier quoted context omitted.

All modes of cyber security depend on some obscurity (e.g. password) Ideally we want a viable plan B, for when it’s leaked/figured out. (E.g. generate new passwords) (For convenience let’s label air-gap as kind of physical security)

> All modes of cyber security depend on some obscurity (e.g. password) That's not what the expression means. "Security through obscurity" has a very specific meaning — that your system's security depends on your adversary not understanding how it works. E.g. understanding RSA is a few wikipedia articles away, and that doesn't compromise its security, so RSA isn't security through obscurity.

I’m aware of that specific meaning. (Hiding under uncommon port, also falls under same umbrella)

But I think it is interesting and useful to detach from that specific label with all connotations, and treat it for a moment as just regular english phrase.

So we can analyse the wider pattern, see why it is deemed flawed, whether it is a binary choice or a spectrum.

(Notable thing to frame the analysis: hacker does not attack RSA, hacker will hack certain implementation of SSH server and use heartblead-v2 to sidestep RSA completely)

Re: Security through obscurity is not bad

#227

Earlier quoted context omitted.

You only need to be faster than the slowest gazelle in the pack, right?

Gazelle bikes are pretty fast ... instructions unclear.

Following Dutch jokes:

Well the lock itself for a junkie in Amsterdam has value if you get expensive one it is additional loot.

Post reply on HN