Live data from Hacker News

Security by obscurity is underrated

utkusen.com

81–90 of 530 posts

Re: Security by obscurity is underrated

#81

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.

But it will stop incompetent attackers - of which there are many. In fact, they are the vast majority.

None of those 'obscurity' techniques will stop a targeted attack. That's not their function. But each of them raises the bar. The more hoops, the better.

Re: Security by obscurity is underrated

#82
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…

I use SSH keys, and disabled passwords. However when I was running SSH on port 22, the number of attempts was slowing my machine to a crawl at times.

Moving the port to some obscure random one divided the number of requests from several thousands per hour to a few per day. Definitely an improvement by any measure : suddenly you can analyze the attacks if necessary.

I run fail2ban on top of it, because why not? In case someone would attempt to really target my system, any obstacle is good to take. And who knows what ssh vulnerabilities exist; any protection is good to take.

Re: Security by obscurity is underrated

#83

In DC there is this concept of "the blob" which is basically shorthand for "The Washington consensus that isn't verifiable, but that most people parrot since to hold an opposing view doesn't really get you anything because even if you're right, nobody will remember. All that they'll remember is that you're that weird guy that looks at stuff with a strange perspective and that you may be too dense to social signal tha…

> But then we all implement passwords (which is just security by obscurity) No it isn't. Security by obscurity is explicitly keeping things other than passwords and keys secret.

I feel like it's a pretty weak point to say that passwords and keys would be security by obscurity if we didn't carve out a special exception for them. Why do they get a special exception? Because they're really really hard to guess, not because they're fundamentally different.

Let me give a real-life example of a good non-password, non-key piece of secret information that's used for authentication. If you need to recover a WoW account that you've lost access to the customer service reps will ask you to tell them the names of the characters on the account. Your account name isn't secret, and your character names aren't secret. But the relationship is because they aren't ever publicly connected. The odds that someone other than the account owner having this information is low and the odds of guessing it by chance is impossible.

Re: Security by obscurity is underrated

#84
post #25

Good, thought-provoking article, but use with caution. I've seen security through obscurity misused too often as the only line of defence, or as a "temporary" stop-gap that outlives its usefulness. It can lead to a false sense of security. Such measures also do not tend to keep up with changes as attacks become more sophisticated or cheaper to carry out. You also need to make sure that there are no unintended consequ…

> I've seen security through obscurity misused too often as the only line of defence, or as a "temporary" stop-gap that outlives its usefulness. It can lead to a false sense of security.

Exactly.

> we need for some reason make this development-stage service publicly available on the internet, and it's connected to a lot of our services internally, but we can implement AAA only later and we need it now. No issue publishing it on an obscure route/IP/domain name?

And the setup stays online for 5 years.

Re: Security by obscurity is underrated

#85
post #61
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.

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.

Re: Security by obscurity is underrated

#86
post #68

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…

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, terrorist organizations would simply start sending Japanese grandmothers.

But of course where it's relatively easy to find young men willing to die for a cause, it's much more difficult to find grandmothers who will do the same. And where it's relatively easy for an Islamic group based in the Middle East to connect to Arabic social networks, it's much harder for that group to connect to Japanese networks.

Re: Security by obscurity is underrated

#87
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 con…

Only the 4th point is really true: if you run SSH on a non-standard port but it's otherwise accessible, you'll still see scans on a regular basis.

Port knocking isn't a terrible idea but I generally prefer locking down the networks (or, these days, using AWS SSM / GCP IAP to avoid listening publicly at all) since having something on the internet means you're just one mistake away from problems and need to staff monitoring accordingly.

The other thing to remember here is that we're talking about one general CVE in two decades. Almost any other running service has been much worse so while SSH is important to protect I don't know that I'd make the argument that further pushing that one service is really the best bang for your buck.

Re: Security by obscurity is underrated

#88
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…

I agree. Obscurity is a weak strategy. If you can make obscurity not necessary you will gain far better results.

It's not a strategy. It's a tactic. And as many others in this discussion have pointed out, people who recommend to use obscurity never tell others to let their whole security strategy hinge on it. It's just a useful tool; a tactic.

Re: Security by obscurity is underrated

#89
post #58

It seems to me that the article is missing a few of points on what "security by obscurity" means. From Wikipedia: "reliance [...] on design or implementation secrecy as _ the main method _ of providing security [...]" So, to use the model mentioned in the article, a single slice of cheese. It's not "an additional layer of defense", it's the main one (so you have other... weaker layers? ¯\_(ツ)_/¯) Second, "reliance on…

I agree with your understanding of security by obscurity. But I think the popular understanding has started to be more along the lines that the author counters. That if any security measure is "obscurity" then don't do it, it's bad.

Re: Security by obscurity is underrated

#90
post #53

In DC there is this concept of "the blob" which is basically shorthand for "The Washington consensus that isn't verifiable, but that most people parrot since to hold an opposing view doesn't really get you anything because even if you're right, nobody will remember. All that they'll remember is that you're that weird guy that looks at stuff with a strange perspective and that you may be too dense to social signal tha…

> "Don't do security by obscurity!" But then we all implement passwords (which is just security by obscurity) Thank you for being someone else who recognizes this. If having a secret piece of knowledge grants you access to the system then it's obscurity. Once we admit that then we can start talking about the difficulty of guessing that knowledge as the actual important factor.

> If having a [password] grants you access to the system then it's obscurity.

Perhaps if you're hiding it under the doormat in front of the door and expecting it won't be found. Or writing your PIN on your ATM card with a sharpie and leaving it on the dash of your car with the doors unlocked and your windows down.

In most cases, however, it's part of an overall system that involves authentication, authorization, and (hopefully!) accounting to protect access to resources.

Post reply on HN