Top
Best
New

Posted by mobeigi 6 days ago

Security through obscurity is not bad(mobeigi.com)
205 points | 214 commentspage 2
grayhatter 5 days ago|
> 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 5 days ago|
> It never* does.

Can you substantiate this claim a bit?

grayhatter 5 days ago||
> 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 5 days ago||
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 5 days ago||
> 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 5 days ago||
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.
caminante 6 days ago||
Regarding Counterstrike (game) example, there were already a lot of cheaters and a cheater ecosystem that still exists to this day. I suspect Valve could address it if it wanted to, but the gameplay/development cost trade-offs aren't enough.

Valve pivoted to server-side anti-cheat and toleration because someone probably did the math on max(profit) with lootboxes.

mobeigi 6 days ago|
Valve's VACnet solution is definitely interesting. It uses AI, deep learning and is server side. It's hard to tell how effective that has been for them compared to traditional client side detection systems; I don't imagine they'll share any results.

The fact that it's completely hidden from cheat developers gives them a huge advantage though. In the past, any client side algorithm or detection method could be reversed engineered by cheat developers and patched before lunch time. Now they're working against Valve completely in the dark.

pona-a 6 days ago|||
Which is a the power of not relying on obscurity. The server not sending you its complete source code is not any more obscure than a secret key.

Security through obscurity is about obfuscating easy-to-recover trivia thinking it buys you any margin, like the client-side anti-cheat handing attackers everything they need to defeat it while trying to then obfuscate that code.

dwa3592 6 days ago||
Security 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.
hunterpayne 6 days ago||
That isn't what the article is talking about. He is literally talking about running the JS code through an obfuscator and changing the default DB schema name. That isn't security and you know it.
i_think_so 6 days ago||
[dead]
tptacek 6 days ago||
Everybody trying to discuss this gets the framing wrong. Obscurity isn't "bad" or "good". It's not "not" security. Security in the real-world sense is about risk. It fixes an adversary and then applies costs to them. Obscurity changes costs (usually by raising them for the adversary).

Depending on the setting and the adversary, obscurity measures can raise costs by a material or immaterial amount.

Obscurity measures usually also impose costs on defenders (and, transitively, on the intended users of the system). Those costs are different than they are for adversaries (usually: substantially lower). They might or might not be material.

Your general goal is to asymmetrically raise costs on the adversary.

Seen that way, it's usually pretty easy to reason about whether obscurity is worth pursuing or not. Don't do it if it doesn't materially raise costs for attackers, or, even if it does, if it doesn't raise costs way less for defenders and users.

What trips people up in forums like this is that we're used to dealing with security problems framed in settings where we can impose \infty costs on attackers: foreclosing all known avenues of attack (to something like a mathematical certainty, and stipulating that computer science discoveries may change the cost function tomorrow). In those settings, all obscurity measures have relatively immaterial attacker costs associated. But it's still the same underlying problem! And, in the real world, we're actually rarely operating in model situations where we really can impose \infty costs on attackers.

TZubiri 6 days ago||
>For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.

>My website was vulnerable. However, I was not impacted by any attacks, and I updated the plugin to a patched version a few days later. While other sites were "nulled" and destroyed, I was spared. I later found a PoC script on GitHub showcasing the exploitation. Using that PoC on my own site failed with a generic error like Table 'wordpress.wp_users' doesn't exist.

The biological sciences fully support this form of protection. One of the main benefits of the whole of sexual reproduction is based on this principle. Mutations introduce diversity to populations which allows otherwise extinction events to just affect a fraction of the population.

So yeah, maybe the university of Open Source internet considers your approach to security to be baseless, but (in addition to your empirical experience), security through obscurity is well recognized in zoology.

danpalmer 6 days ago||
> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.

In some ways this is not security through obscurity. If you don't have a way to enumerate tables, this is in effect another short password being added to the data. In the same way you could say that the "obscurity" of users' passwords is security through obscurity... except we still use passwords.

The idea of security through obscurity being bad stemmed from the idea that a cryptosystem should still be secure when you know how it works. That's all.

In that way, you know how WordPress works, and yet you don't have access. You know how passwords work, and yet don't have access.

Obfuscating code is interesting because it sort of sits between the two. You could execute the code, and you may know how the obfuscation scheme works, but you can't de-obfuscate easily and see the original intent, and that way it's useful. The fact that you can still execute the code does however limit the impact.

josalhor 6 days ago||
I want to add that Obscurity is ambiguous. Is changing the port of SSH "obscurity"? Some may say yes, because you could find it by bruteforce. But a password with infinite attempts can also be bruteforced. Here, the defining factor of security is maximum number of attempts (either on ports, username or whatever).
trashb 5 days ago||
Security is the lock on the safe.

Obscurity is the information you need to find the safe.

All security can eventually be broken, given enough time, this is why A very useful measure for the security of a lock is how long it takes to break. The same is true for cryptography.

Obscurity can add a buffer before you can start breaking the lock and it can act as a deterrent for opportunistic attacks. Additionally it can help with signal to noise and monitoring of the lock.

This is why you have a lock on your front door and don't tell anyone you meet where exactly in your house you store your valuable jewels (preferably out of sight). You also want to monitor anyone in your garden more closely than on the road passing by.

allknowingfrog 5 days ago|
Isn't it all just information? The lock code and the location of the safe are both just data. I think it's possible that all security is obscurity.
TZubiri 6 days ago||
The source of this bias is voyeurism.

It's always someone outside your org telling you that obscurity is bad, and that you should definitely publish all your source code to let them see.

It's self serving outside judgment to get you to provide them value.

On the other side of the coin, there is a bias towards this trope that comes from exhibitionism: those of us who hold that security through obscurity is valuable, will usually not publish our thoughts on other security mechanisms, since we will consider that doing so decreases our security, whereas those that believe in the trope, will publish all of their thoughts on security, as they do not depend on or value the secrecy of their strategies.

high_na_euv 6 days ago|
Wtf, why ppl struggle so hard with simple concept

Obscurity increases the bar, and now, some actors will be prevented just by it, some delayed and some not affected at all, but after all you dont know who is attacking you and their skills!

viccis 6 days ago|
It's just a good component of a defense in depth approach. Where it's bad is when it's the only defense. Putting a sensitive server behind port knocking will cut down on 99.99999% of random internet IPs spraying attacks at it, so it's worth doing. Just don't rely on it for the only auth check.
More comments...