Live data from Hacker News

Security by obscurity is underrated

utkusen.com

101–110 of 530 posts

Re: Security by obscurity is underrated

#101
post #65

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…

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

This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is changing the default SSH port. Just by obscuring your port you can usually filter out the majority of break-in attempts.

The only way security through obscurity signals to "predators" is if they've seen past your defence, and thus defeated the obscurity. Obscurity (once revealed) is not a deterrent. Likewise an authentication method (once exploited) is not a deterrent.

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

This is true of any exploit basically. Look no further than metasploit. Another example: a worm is a self-automating exploit.

Re: Security by obscurity is underrated

#102
The way I think about this, there are some aphorisms that work as actual design principles, and some that are just used to defend a decision you have already made to someone who doesn't need to understand it.

"There's no such thing as security through obscurity" is an example of the second; you can use it to mean "shut up and stop asking questions about the secure system I designed," but you can't use it to design a secure system or explain why your choices are correct.

The useful design principles behind "no security through obscurity" are just a little more complicated -- they're more like "every secure system must have defined entropy sources (such as keys) that provide a lower bound on the security budget against a hypothetical attacker with knowledge of everything except for the entropy sources." And, "because obscurity does not measurably improve the lower bound on the security budget, it is only a good idea if it also does not raise the chance of implementation errors, does not make it harder to obtain third party reviews of the system, and does not make the security of the system harder to prove." An argument about whether something is security-through-obscurity-in-a-bad-way probably actually wants to be an argument about an underlying design principle along those lines.

I don't exactly begrudge people using "shut up and trust me" phrases in situations where that's needed, but I think they're almost always unhelpful in forums like this.

Re: Security by obscurity is underrated

#103
post #85
post #61

Earlier quoted context omitted.

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.

I could be wrong, but if you are using public/private keys to authenticate to ssh, then even attacks that can listen in on the connection would be limited. Because the private key is never transmitted, unlike a password.

With heartbleed, a bug in the implementation of the protocol led to the server randomly leaking contents of the server’s memory, which could be anything from private keys to user or system passwords to other confidential information. No passwords or MitM was required. You can read more at heartbleed.com

Re: Security by obscurity is underrated

#104

There is a reason the military doesn't paint their tanks bright pink... Armor is important, but if you don't get shot at in the first place, even better.

Security by obscurity is not painting tanks in camo. Security by obscurity is assuming your enemy won't find your tanks because you didn't broadcast on public radio where your tanks are.

Re: Security by obscurity is underrated

#105
Agree with most people here that security by obscurity is bad "by itself".

For example, changing your public server ssh port from 22, to say, 2942, is a great way to limit the amount of bot autoattempts from trying to log into your server. Having a password-less ssh port 2942 open is clearly bad, but not when combined with all the standard good practice ssh security.

Re: Security by obscurity is underrated

#106

    Yes, I scan them all: 53.2%
    No, I use default scan: 46.8%
    186 votes
Well, I doubt that. My private VMs have had ssh listening on some random port for the last decade, after I was annoyed how the auth.log became an inreadable spam-fest. Now it's been well over a year since the last probe.

Maybe the author's pentesting pals do that on a few public /24 or some intranet (I would, if I was a pentester). But you're average bad guy scanning /8 blocks looking for an easy catch? Maybe with a botnet...

(TBH, I focused on security/crypto during university, but ended up in an other field - so my practical knowledge is limited).

Re: Security by obscurity is underrated

#107

Earlier quoted context omitted.

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…

One of the first widespread security vulnerabilities I had to deal with was this one:

https://www.giac.org/paper/gcih/115/iis-unicode-exploit/1011...

You could basically encode DOS commands in the URL bar for a site running IIS and it would run remotely.

The automated attack basically replaced the index.html pages. But if you didn’t use the default pages. It didn’t have any effect.

Re: Security by obscurity is underrated

#108
post #72

Earlier quoted context omitted.

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…

It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none.

Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value.

In reality an attacker is just going to dump strings and try them all or simply set a breakpoint just before the important syscall and let your program do the work. Code obfuscation provides little to no value for these common methods, yet we cannot resist the urge to list it as a bullet point in security meetings, leading to a false sense of security.

Re: Security by obscurity is underrated

#109
Article misuses/misunderstands the term "security by obscurity", and is attacking a strawman position based on its own definition of what it means.

Security by obscurity refers to a situation where security is dependent on the secrecy of an algorithm (the algorithm not being widely known or peer reviewed) rather than (or in addition to) a secret datum used with that algorithm.

The opposite practice is to use a well-known algorithm and depend only on the secrecy of the inputs to that algorithm.

The layers of security presented in the article do not meet the definition of "security by obscurity".

Even a port number like 64235 is a secret datum, not a secret algorithm. It's not a hard-to-discover secret datum; it is poorly guarded. But that's not what "security through obscurity" means. Using a funny port number is a widely-known system, with an objective benefit: it requires an attacker to take certain steps that are not required with a known port number. The assumption is that the attacker knows that alternative port numbers are being used.

Post reply on HN