Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security by obscurity is underrated

utkusen.com

Post reply on HN
Print view View original

71–80 of 530 posts

Re: Security by obscurity is underrated

#71

Post by historyremade »

weare138 wrote: post #44
cataflam wrote: post #13

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…

But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In y…

By your logic, We don't need borders at all.

Re: Security by obscurity is underrated

#72

Post by umvi »

weare138 wrote: post #44
cataflam wrote: post #13

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…

But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In y…

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there.

There is still some information lost in the process:

- "let eigenvector_coefficient = 23" => "let x = 23"

A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to spend an order of magnitude longer trying to understand what the code is doing.

> Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.

Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit.

Remember, the goal is to "reduce risk" and not "stop any highly skilled targeted/tailored attack". Because let's face it, even if you are the greatest crypto wizard in the world, you will fall victim to a highly sophisticated attack tailored specifically to you.

Re: Security by obscurity is underrated

#73

Post by aeternum »

cataflam wrote: post #13

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…

It's fine as an additional layer only when the primary layers do not rely on obscurity.

I've seen too many instances where obscurity is used to justify weak primary layers (IE it's fine we're using this single word shared password since we have all these other layers). It can often provide a false sense of security since it looks like a security layer when in reality it often turns out to simply be a minor inconvenience to an experienced attacker.

Re: Security by obscurity is underrated

#74

Post by vsareto »

derefr wrote: post #36
vsareto wrote: 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…

I don't disagree, but this kind of goal post moving is how zero cost will turn into a buzzword down the line because it'll really mean zero incremental costs when referring to operations.

Plus, zero incremental costs may only apply if you match the situation being presented. If not, you may have real costs associated with implementing obscurity. This evaluation of whether you will get zero incremental costs or not is a cost in itself.

It's just a misappropriation of the term from zero cost abstractions and it bugs me, especially since it's being ported from compiler theory/engineering to operations, two things which rarely have anything to do with one-another.

They'd be way better off coming up with "cost-effective obscurity" ideas, instead of calling this zero cost.

Re: Security by obscurity is underrated

#75

Post by drewg123 »

Almost 2 decades ago, I maintained our company's self-hosted web server on FreeBSD/alpha. It ran a simple (thttpd) web sever. I remember looking through the logs, and seeing script-kiddie attack after attack fail due to running thttpd instead of apache, FreeBSD rather than Linux, and alpha rather than x86.

I obviously kept the machine patched and up-to-date, but I think I probably could have left it unpatched, and it still would have been fine.

Re: Security by obscurity is underrated

#76

Post by typon »

weare138 wrote: post #44
cataflam wrote: post #13

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…

But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In y…

> competent pen tester

So it does eliminate incompetent ones? That's kind of the point of the article.

Re: Security by obscurity is underrated

#77

Post by drchopchop »

weare138 wrote: post #44
cataflam wrote: post #13

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…

But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In y…

>Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.

Sure it will. Imagine that your old, unpatched Wordpress admin is at /random-gobbledygook instead of /wp-admin. An attacker would have to try to hit random alphanumeric directories of your webserver over and over again, hoping that he stumbles across a specific thing that they can attack. This is completely impractical, unless they're somehow clued in that the URL exists.

It's really about making life difficult for an attacker, so much so that they will simply give up, or find an easier target. That can be achieved by throwing up a series of difficult/obscure barriers, each which makes it less likely you'll be trivially penetrated.

Re: Security by obscurity is underrated

#79

Post by hackinthebochs »

formerly_proven wrote: post #55
fooblat wrote: 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…

> The claim was never that using obscurity is bad and should be avoided. Yet. All of these are from HN. > 3. Since when is obscurity a valid security measure? > Security through obscurity, not a valid security plan. > The problem with these "obscurity as a valid security layer" arguments is that there's already obscurity built into these protocols. > Especially since most people believe "Obscurity" to still be a vali…

It helps to remember that nuance is lost over time as recommendations of best practices become memes. It's useful to reiterate the valuable nuance on occasion to be sure people aren't just taking the memes at face value, as you can be sure some amount of people are.

Re: Security by obscurity is underrated

#80

Post by skipants »

weare138 wrote: post #44
cataflam wrote: post #13

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…

But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In y…

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there.

Then it filters out people who are not using a deobfuscator or are less clever than I.

> Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.

Then it will stop incompetent pen testers.

I don't see how your comment refutes the point made. The point is not that it makes your likelihood of attack zero, it just reduces the likelihood via adding more roadblocks.

Post reply on HN