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

61–70 of 530 posts

Re: Security by obscurity is underrated

#61

Post by p49k »

tptacek wrote: post #27

There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…

Heartbleed caused data leakage in the handshake phase of the protocol. I don’t know if SSH was affected, but there’s no reason why a similar exploit won’t be found for SSH in the future, and trivially obscuring your SSH port protects you from 99.9+% of automated attacks, possibly buying you time to patch or mitigate.

Re: Security by obscurity is underrated

#62

Post by gumby »

By definition cryptography is security through obscurity as you map something from a small space into a large space (e.g. multiplying Two numbers you know is easy while finding two prime factors is hard).

The aphorism is unfortunately too short to be enlightening except to someone who already understands it.

Re: Security by obscurity is underrated

#63

Post by salamander014 »

abhishekjha wrote: post #32

This came up in the stackoverflow podcast where Reddit founders were the guest. They mentioned that they stored plain text passwords initially which is fundamentally a bad design but at the same time it helps to block spam. If a user starts to create a lot of accounts programmatically they generally use the same password thus much easier to filter. Security via Obscurity, if you can do it, can be very very effective.

It's possible to track similar passwords in a safe way over a short amount of time. Keeping any user's password or any security token in plaintext is just disgusting. Regular people have a hard enough time navigating the digital world without needing to worry about whether their credentials are safe. Anyone who stores passwords in plaintext is disgusting and should not be managing digital services. Period. This is how breaches happen, and it should be a fine-able offense.

Re: Security by obscurity is underrated

#64

Post by mercer »

_tk_ wrote: post #45

To maybe give some perspective _why_ security people say that security by obscurity is bad - and especially serving ssh via port 64323: Typically you want to know who is connecting to what server via what service and log these connections. If something is off, an alert can be generated. If ssh isn't served on a standardized port, logging and alerting becomes more complicated - albeit not impossible. There is more hou…

> Typically you want to know who is connecting to what server via what service and log these connections. If something is off, an alert can be generated. If ssh isn't served on a standardized port, logging and alerting becomes more complicated - albeit not impossible.

Could you elaborate on that? I serve ssh on a non-standard port precisely in part because it drastically cut down on the noise of failed log-ins, to the point where when I check the logs I'm almost the only one who actually bothers to try to log in via that port. That seems like a win to me.

Re: Security by obscurity is underrated

#65

Post by Verdex »

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…

In nature, prey animals will sometimes jump when they spot a predator[1]. One of the explanations is that this is the animal communicating to the predator that it is a healthy prey animal that would be hard to catch and therefore the predator should choose to chase someone else.

I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up.

Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it.

Of course, sprinkling a little bit of obscurity on top of a good security solution might provide an incentive for attackers to go someplace else. And I can't help but think of the guy who was trying to think of ways to perform psychological attacks against reverse engineerers [2].

[1] - https://en.wikipedia.org/wiki/Stotting

[2] - https://www.youtube.com/watch?v=HlUe0TUHOIc

Re: Security by obscurity is underrated

#67

Post by GiantSully »

corytheboyd wrote: post #5

Please do not use random variable names in source code. Uglify/minify instead. It’s a bit unclear because right above that “tip” is obfuscating code, did I miss something?

Guess obfuscation is the goal, and the methods include using random variables, disordering code, inserting verbose code...

Re: Security by obscurity is underrated

#68

Post by jerf »

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…

You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. That's the wrong model. It's about costs. Obfuscating otherwise-open code doesn't mean that nobody can ever figure out what it does, but it raises their costs. Randomizing variables raises costs. Encrypting the DB raises costs on an amortized basis (some cracks may get the key and then it may not raise the cost much, but other cracks may only get the data in which case cost is raised a lot). Things are "secure" not when it's impossible for any actor in the world you don't want to get access to get access, but when the costs to those actors exceed the loss you may experience. (Preferably by a solid margin, for various reasons.)

As to whether this is good or bad advice, that depends on how expensive these things are (e.g., encrypting database fields may be very expensive if you write raw SQL calls as your primary DB interface but may be dirt cheap if you're using an ORM that has it as a built-in feature) and your local threat model (e.g., "dedicated, personalized attackers reading your source" is very different from "does it defeat automated scanners?"). You can't know whether these are good or bad ideas without that additional context.

Re: Security by obscurity is underrated

#69

Post by justinsaccount »

tptacek wrote: post #27

There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…

> Just use SSH keys, and disable passwords.

CVE-2001-0144 - SSH1 CRC-32 compensation attack detector allows remote attackers to execute arbitrary commands on an SSH server or client via an integer overflow

CVE-2008-0166 - OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to conduct brute force guessing attacks against cryptographic keys.

I had a machine almost get compromised from the 1st vulnerability ( noexec on /tmp broke their script ). When the 2nd came out I was using non standard ports and or port knocking. Despite having vulnerable keys I was safe until I could upgrade.

If a SSH RCE 0day was released:

* every "Just use SSH keys, and disable passwords" box sitting on the internet with ssh on port 22 will get compromised within hours.

* The boxes using fail2ban will get compromised within hours.

* The majority of boxes on nonstandard ports would likely be ok, at least for some time.

* The boxes using port knocking would be safe.

Re: Security by obscurity is underrated

#70

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…

And Asshole it take time to deobsufucate no matter how clever as you are
Post reply on HN