Live data from Hacker News

Security by obscurity is underrated

utkusen.com

291–300 of 530 posts

Re: Security by obscurity is underrated

#291

Earlier quoted context omitted.

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

> * The boxes using port knocking would be safe. No, saf er . It is very well possible to brute-force port knocking or eavesdropping the ports since that information is not encrypted. Is it harder? Of course, a lot, but if you think scanning 65k ports on each host on the internet is reasonable, then evading a port knock is very much, too.

> It is very well possible to brute-force port knocking

It's incredibly unlikely - there is probably more chance of the sun imploding tomorrow. And if you're the type to install port knocking, you've almost certainly also installed something like LFD, which will temporarily block IPs for port scanning.

Also, without inside information, how would you even know that a server was using port knocking?

> unlike

Re: Security by obscurity is underrated

#292

All software security comes down to obscurity: it depends on the selection of specific numbers that are known to the authorized parties, but are extremely difficult to guess (i.e. very obscure) to the unauthorized parties. The extreme of this strategy is to make a successful guess cost more than anyone can possibly pay, for example by using numbers so obscure that all known algorithms for guessing them will take long…

Security can also be achieved by physical separation or identity based on physical human traits. Now we're getting philosophical, but if the security crew of the data center knows my face, and does not allow other people to enter, would you reduce my face to a value that is "extremely difficult to guess"?

Re: Security by obscurity is underrated

#293
post #242

Earlier quoted context omitted.

Why not just block SSH access from the public internet and use a VPN? Trivially easy to setup and more secure than knocking. All it takes is me somehow being able to listen in on your traffic - not even decrypt it - and now I know the knock sequence. I know that you have SSH listening on that server. I know you are actively doing something on it. vs. a VPN where... all I know is you are communicating over a VPN. With…

Again, this is where all port knocking debates devolve to ... Port knocking is not the christ child that will wash away all of our sins ... and therefore is not worth implementing. You're right! It doesn't add that much . But it's non-zero and has almost zero cost. It's very elegant, in my mind, and it makes me very happy.

Like you said.. "worry less"

Can a theoretical attacker intercept a port knocking sequence? maybe. Would a script kiddie running a new ssh 0day against the entire internet be able to do this? no.

Re: Security by obscurity is underrated

#294
post #242

Earlier quoted context omitted.

Again, this is where all port knocking debates devolve to ... Port knocking is not the christ child that will wash away all of our sins ... and therefore is not worth implementing. You're right! It doesn't add that much . But it's non-zero and has almost zero cost. It's very elegant, in my mind, and it makes me very happy.

I guess my point is largely: I can set up a VPN in a roughly similar timeframe to setting up port knocking, and it has roughly similar overhead for end user, but the VPN gives me significantly more security while also solving the same issue port knocking does. In that case, why not just set up a VPN instead of port knocking?

I will again agree with you that the VPN is a more robust and more complete protection. You are correct.

I think the reason I continue to prefer (and evangelize) port knocking is that the intersection of (modest) security gain and simplicity/robustness hits a sweet spot for me.

Again, 10+ years in production on many hosts, worldwide, and never so much as a blip. IF knockd were to fail, it would fail in a very boring way. VPNs, on the other hand, are far more complex and they fail in fascinating ways.

I am a sysop turned sysadmin - this is my lifes work. I prefer simple, unixy tools that fail in boring ways :)

Re: Security by obscurity is underrated

#295
post #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…

I was going to make approximately this point. However, I think it's also important to have some of those "shut up and trust me" phrases codified and have them available for the layman via Google. Because sometimes those people demand "proof" or they'll go searching for it themselves and if it's right there to be found and most major sources agree... well, the discussion can then be "Is this just obscurity where security is needed?" AS IT SHOULD BE.

If you get right down to it, passwords are just obscurity. Usernames are just obscurity. In this very thread people are dismissing port knocking while it's functionally equivalent to a password.

I will personally stand by "security through obscurity is not security" forever because that way we can get to the actually interesting question -- what level is needed for this service?

Let's take a simple example from the public Internet -- you want to share something. So you put it on a server with Apache. You add TLS and PFS. You hide it in a folder structure somewhere. You add a single-use token or just htaccess.

Any of those individually would be obscurity, but put together they are most likely more than enough for... well, anyone. So is it still obscurity or actual security? That's a debate for the ages, but I think most people would agree all of those put together are fine-ish, but pick just one method and it's just obscurity.

This whole thread is basically just a philosophical debate where half the people haven't read the article, the other half disagrees with minutiae in the article, the third half disagrees with major points of the article, the 4th half is sharing anecdotes and the 5th half just wants to participate.

Re: Security by obscurity is underrated

#297

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…

Changing a port adds one bit of entropy. Not being forced to use "admin" as a username adds a whole bunch, but at least one bit. Not being forced to use https://url/admin also adds another bunch, but at least 1 bit.

Of course, if any of these things are known the entropy drops to zero... Just like a private ssh key that gets pwnd.

All too often I see tickets on open source projects asking for changes to allow better obfuscation, which are then denied using the mantra "obscurity is not security".

They all add bits of entropy to a security and/or threat model that maintainers ignore.

Re: Security by obscurity is underrated

#298

It's like a painting in front of a safe: - doesn't reduce the security of the safe - ensure you don't advertise "THERE'S A SAFE HERE" to whoever visit your house, possibly reducing burglar attempts Now, if you have just the painting over a hole in the wall, you got something wrong...

Now, assume that every painting in your house can be checked for a safe behind it in milliseconds (total, for all safes) by the people in your house. Did you actually accomplish anything?

Why would you think it's in milliseconds? Are you generalising on port scanning? You could say that uuid as urls are obscurity, but it's not that fast to break through (and then hopefully you get some kind of protection layer)

There's also an additional monetary cost for the attacker, it adds up

Re: Security by obscurity is underrated

#299

Earlier quoted context omitted.

I guess my point is largely: I can set up a VPN in a roughly similar timeframe to setting up port knocking, and it has roughly similar overhead for end user, but the VPN gives me significantly more security while also solving the same issue port knocking does. In that case, why not just set up a VPN instead of port knocking?

Which vpn though? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pulse+secur... VPN doesn't magically fix all problems. wireguard is good so far, but the kernel implementation is in C, so who knows.

No, a VPN isn't magic in and of itself. And yes, I would suggest wireguard for the simplicity and performance these days.

I do agree with the author of the original article that security should come in layers

Once something is secured with SSH and a VPN, you've got that many more actual layers - you now need a CVE that allows access or credential leak for both the VPN and SSH. (And many of those CVEs don't necessarily allow a random attacker to arbitrarily gain access)

https://news.ycombinator.com/item?id=24446919 has my list of what the bare minimum SSH protections should be for anything where you are storing customer/user data in my opinion, as well as additional best practices that I have employed.

Re: Security by obscurity is underrated

#300

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 know someone who would rather store passwords/api keys in the database encoded in a way that is not clear text but is not encrypted or hashed arguing that its overkill to encrypt.

Obscurity instead of Security is bad too.

Post reply on HN