Live data from Hacker News

Security by obscurity is underrated

utkusen.com

181–190 of 530 posts

Re: Security by obscurity is underrated

#181
post #76

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…

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

If you have any bit of real security, incompetent people wouldn't pose a risk.

So, what's the gain?

Re: Security by obscurity is underrated

#182
Security by obscurity was the perfect way to send the largest diamond across the world:

"Due to its immense value, detectives were assigned to a steamboat that was rumoured to be carrying the stone, and a parcel was ceremoniously locked in the captain's safe and guarded on the entire journey. It was a diversionary tactic – the stone on that ship was fake, meant to attract those who would be interested in stealing it. Cullinan was sent to the United Kingdom in a plain box via registered post." - https://en.wikipedia.org/wiki/Cullinan_Diamond

Re: Security by obscurity is underrated

#183
One downside of security by obscurity is that it makes it harder for whitehat people to spot problems in your code. It is like asking everyone $1000 to look at your source code. It is relatively more likely to deter whitehats since their upside is lower.

Re: Security by obscurity is underrated

#184

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…

Hell yes, couldn't agree more. This last year, I found out about knockd and if that isn't some awesome shit, I dunno what is. Yet, there are plenty of articles saying, incorrectly, how it's awful. It is simply another layer of security on top of everything else you have. Like you said, security by obscurity is more about making it fucking slow, irritating, tedious, and without any sense of reward. "Aha! After only a…

Also don't forget that relative effort matters too. Consider "The Club" protection for cars - in a lot, the one with The Club is chosen last to break into just due to its relative difficulty. (Weighted against the potential upside, obviously.)

The port knocking itself may actually be the strongest link in the chain, despite it being one of obscurity, if the population of targets in your "value pool" is large enough so that you are always below a sufficient number of others without knocking enabled, since all attackers will bounce to those when they realize they are not knocked.

Re: Security by obscurity is underrated

#185

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…

Security by obscurity is bad. Obscurity alone does not provide much security especially in a cryptographic setting. It can not be relied on as your sole protection.

Security and obscurity: if you make something secure and then obscure information about that system from an attacker that can increase the security. However obscurity is often organizationally expensive and very fragile. A key can be rotated, but changing how something functions is very hard to rotate.

Re: Security by obscurity is underrated

#186
post #155

Earlier quoted context omitted.

Using obfuscation is often a signal that you are a weak target, because there are a lot of places that use obfuscation but nothing else. A better indicator that you are a hard target is to enable common mitigations like NX, stack cookies, or ASLR.

There is one giant hole in your argument: both stack cookies and ASLR are mitigations that are nothing more than automated security through obscurity in the first place.

How so? Stack cookies and ASLR are a form of encryption, where an attacker had to guess a random number to succeed in an attack.

Obscurity really just boils down to a secret that doesn't have mathematical guarantees. It's doing something that you think the attacker won't guess, just like an encryption key, but without the mathematically certified threat model, so you just hole that the attacker is using a favorable probability distribuy for their guesses

Re: Security by obscurity is underrated

#187

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…

I agree with the principle, but I disagree with the article's example of changing the SSH port as an example of obscurity. Lots of people set up SSH servers on multiple ports, especially in the case of relay servers that provide access to multiple machines through one IPv4 address.

A better example of security by obscurity would be to, for example:

* Flip all the SSH bits or XOR it with some long key.

* Encapsulate SSH inside another protocol, such as websockets over HTTP port 80, or embedded inside what look to an outsider as cat pictures being sent over HTTP.

* SSH over TCP over Skype video.

Incidentally, any of these methods work well for confusing China's firewall and keeping the SSH connection alive, and would probably confuse hackers as well for a little while. They could all be implemented in a router box that doesn't affect your actual deployment.

Re: Security by obscurity is underrated

#188
post #68

Earlier quoted context omitted.

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…

> 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. This is something that bothered me quite a bit in Bruce Schneier's various comments on airline security. He repeatedly wrote that profiling young Arab men as likely terrorists was pointless, because if it became harder for young Arab men to get through security, terro…

This is also absent in the analysis of "security theater." I've often felt the "theater" does in fact have a material impact on target selection. One doesn't need to actually have a methodology that results in better capture of terrorists to deter them to other targets: one just needs a methodology that has plausibility of increasing the risk of failure. The unfalsifiability of "security theater" is actually a feature not a bug: it means there's always a non-zero weight on it's potential risk impact to terrorist considering air travel as a target.

All other things being equal, the opportunity cost will shift towards targets that have less elements akin to "security theater", since it's basically 'money on the table' to de-risk the attack.

So, the real question to ask about "security theater" is not if it has a material impact on human safety with flying, but if its deterrent effect pushes risk to places we'd rather it not go or if the costs of performing it do not outweigh this deterrence benefit. Given the potentially paralyzing effect it would have on the global economy if air travel were covered in a blanket of fear of flying, it's hard to argue that "decentralizing" this risk to other targets is a bad idea.

Re: Security by obscurity is underrated

#189
post #143

Earlier quoted context omitted.

Agreed. The maxim warning against "security from obscurity" is often reduced to an irrational comprehensive avoidance of obscurity. It's similar to the irrational avoidance of all performance optimization because Knuth warned of premature optimization. Both reductions lose practical utility by omitting nuance. * Avoid wasting your time doing performance optimization until tuning is necessary. But definitely take obvi…

> But definitely take obvious and easy measures that leverage obscurity to add another layer of defense, such as changing default ports, port-knocking, or whatever. Except that can lead to operational problems down the road. For example "oh yes, we're nice and secure, not only do you need a 512bit private key to get into this device, you also need to connect from a secure network" Then along comes covid, and you can'…

Of course security can lead to operational problems. Security is a trade-off against convenience.

Re: Security by obscurity is underrated

#190
post #42

No mention of port knocking for SSH. I used to be scanned constantly for SSH logins. So I changed the port. The login attempts stopped for awhile, but eventually they found the port. Now with port knocking, I haven't seen a single attempt. Security by obscurity alone is bad, but as another layer, it can be great.

> Security by obscurity alone is bad, but as another layer, it can be great. I beg to differ in your case. Had you left SSH on its default port, what would your expected time-to-compromise be? Presumably you weren't using a root:password credential, or else your system would not have remained up enough long enough for you to implement any obscurity. But if an attacker, with full ability to try logins, could not reaso…

I disagree. Suppose the latest SSH has a 0-day, now I am vulnerable, even though I only use PK-auth. Obscurity is just another layer, and the purpose of layers is to help make rare vulnerabilities (like 0-days) not compromise the system. By hiding the door, they cannot even touch the 0-day without another rare vulnerability.
Post reply on HN