Live data from Hacker News

Security by obscurity is underrated

utkusen.com

331–340 of 530 posts

Re: Security by obscurity is underrated

#331

The article is correct but they miss the true value add of security through obscurity: signaling lower ROI to attackers. Security through obscurity generally forces attackers to perform more actions and do more recon. Every additional action taken increases the risk of detection by defenders, costs the attackers valuable time (meaning lower ROI), and makes the target less appealing relative to other targets. Security…

>The article is correct but they miss the true value add of security through obscurity: signaling lower ROI to attackers. Security through obscurity generally forces attackers to perform more actions and do more recon.

Exactly. I came here to say much the same thing, except with a non-digital analogy.

I live in a (relatively) small apartment building with five floors and four apartments on each floor.

I live on a floor that isn't the top or the bottom floor. That reduces the likelihood that someone who opportunistically gains access to the building entrance or the roof will attempt to access my apartment.

What's more, unless I'm being specifically targeted (which obviates any sort of obscurity argument, given that specific focus is given to a target rather than a service exposed by many), it's pretty unlikely that my apartment will be robbed since there are other, much more accessible apartments than mine.

That's the "security through obscurity" bit, which has a measurable, positive impact on the security of my home and belongings.

However, that doesn't mean locking my door is inappropriate or overkill.

In fact, if I am being specifically targeted, locking my door is likely not sufficient either, as an intruder could bash down my door or drill out the locks to gain entry.

I suppose I could install surveillance cameras focused on my front door (as well as inside my apartment), allowing me to identify intruders after the fact. And I could install safes to hold my valuables as well.

Each of those security precautions have some positive value, and absolutely contribute to the idea of "defense-in-depth".

That said, there is a real trade-off between increased security, cost and usability.

While the relative "obscurity" of my apartment confers some security value, it's not nearly enough to stop someone from trying all the doors in the building, so I lock my door. I don't, however, have safes in my home or surveillance cameras outside the door and in every room, as that (unless I'm being specifically targeted) doesn't add enough value to justify the cost of such measures.

Which brings us to the point of security -- which is to protect assets. However, if the cost expended (in resources and usability) is greater than the value of the asset(s) being protected, it doesn't make sense to do so.

Security through obscurity can (but doesn't always) provide a modicum of value, but isn't a complete solution itself. Used in conjunction with other, reasonable (in the context of cost vs. value being protected) measures, it can be a valuable tool.

Re: Security by obscurity is underrated

#332

Earlier quoted context omitted.

>ssh non-standard port is actually a good thing given the massive amounts of bots around Except that if you use a port above 1024 (like the author does) you no longer have assurances that it is a privileged user that launched the process. Any non-privileged user on a Linux system can bind to a port higher than 1024, so all it takes is sshd restarting after an update if it's directly listening on a high number port, o…

Never thought about this before, but is this a tunable thing in the kernel config? Some way to signal to the OS "only use port ranges above 16382 for unpriv" and move the boundary up?

Most distributions come with a 'portreserve' daemon for just this purpose.

Re: Security by obscurity is underrated

#333

Earlier quoted context omitted.

eavesdropping, maybe. There are tools like https://github.com/mrash/fwknop that are not vulnerable to that or brute-forcing. But brute forcing in general? not a chance. There are 18446744073709551616 4 port sequences.

And there are roughly 1267650600228229401496703205376 port 22's in the IPv6 space - I've substracted a few for reserved and unassigned spaces, but at this scale a few orders of magnitude hardly matter. Here, for comparison: 281474976710656 - total ports in IPv4 space 18446744073709551616 - 4 port combinations 1267650600228229401496703205376 - my estimation for 22 in IPv6 And if you don't block the knocking when recei…

18446744073709551616 is 65 bits. Let’s simplify, you're trying to guess a number in 2^64 You can’t guess in parallel. Reasonable constraints on the server side (i.e. limit tries on the combination/per hour before suspending ssh for a while) may have been implemented.

I’d say cracking that is… Unfeasible.

That also assumes you know the existence of a server on which there is ssh under an unknown combination of port knocking of length 4.

Re: Security by obscurity is underrated

#334

Earlier quoted context omitted.

Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Since the number of ports is quite large, there is also a correspondingly large number of possible port sequences so you can't, in principle, brute force it without a lot of effort.

> Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Yes. But you also have to know that port knocking is enabled at all. That's the obscurity part.

Gotcha. Fair point.

Re: Security by obscurity is underrated

#335

Earlier quoted context omitted.

I think a lot of the people in this comment thread are missing the point when using the `sshd` example. There is no single infallible way to secure ssh, but there are a lot of things that can be done together to make it pretty darn hard to hack, and most of those countermeasures have some degree of 'obscurity' to them. Example: * Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits…

>* Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and I'm replying to these suggestions all over this item because I think it's important, so I apologize if you've since seen this comment elsewhere, but: This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. If you restart sshd for a software upgrade…

> This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22.

My firewall does port mapping so externally it's not 22, but internally it is.

Re: Security by obscurity is underrated

#336

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…

Well put. Using it as an additional layer isn't bad.

Re: Security by obscurity is underrated

#337

Earlier quoted context omitted.

> The claim was never that using obscurity is bad and should be avoided. Yet. All of these are from HN. > 3. Since when is obscurity a valid security measure? > Security through obscurity, not a valid security plan. > The problem with these "obscurity as a valid security layer" arguments is that there's already obscurity built into these protocols. > Especially since most people believe "Obscurity" to still be a vali…

> Obscurity is bad because it makes you _think_ it adds security. I agree with the OP, but I also fully agree with this point. I've seen people download the fishiest stuff or open anything because "I have an antivirus installed". Now, I don't claim that no AV would be better in all cases, but it is very much a factor.

But it's not like that is it. Try to guess the model number written on my monitor.

I'll wait...

Re: Security by obscurity is underrated

#338

Earlier quoted context omitted.

This is the whole "shadow IT" that actually results in a lot of security breaches. Look at the recent twitter hack for a great example. Staff were storing login credentials in a slack pinned message because using the right tools were a headache.

One thing I despise is internal systems with self signed certs because setting it up properly is a faff or no one can agree on the latest and greatest way to do it. Oh cool that’s fine I’ll just click away all the big scary warnings in my browser to access this page. I’m an engineer and know what I’m doing! It’s a super strong key anyway. Oh wait I’ll just send this link to Bob in accounting and tell him to do the ve…

Part of the blame here should go to web browser developers. Self signed certificates pop up a huge warning while plaintext http connections do not, even though the former is more secure than the latter.

Re: Security by obscurity is underrated

#339

In Applied Cryptography, Schneier says obscurity is "take a letter, lock it in a safe, hide the safe somewhere in New York". Somehow in my mind, cryptography, eg. RSA, is also obscurity then. But instead of obscuring the physical coordinates in the set of coordinates of New York, we obscure the location of the private key in the set of prime numbers.

Lock it in the safe, hide it ... but then forget about the safe and make sure everyone else has as well.

Then it doesn't exist.

Re: Security by obscurity is underrated

#340
post #330

Earlier quoted context omitted.

>ssh non-standard port is actually a good thing given the massive amounts of bots around Except that if you use a port above 1024 (like the author does) you no longer have assurances that it is a privileged user that launched the process. Any non-privileged user on a Linux system can bind to a port higher than 1024, so all it takes is sshd restarting after an update if it's directly listening on a high number port, o…

This is the reason the 'portreserve' application exists.

Kind of. It doesn't actually solve this. At most, it makes it a race.

If you are using portreserve for the port, the portreserve daemon just holds it until your actual application calls portrelease and then binds to it. If all reserved ports are released, the daemon exits. For a service restart, you could add starting up the daemon as part of the process, however, it is still a race to try and bind to that port. If sshd crashes, there is no reason that portreserve would try to bind to that port. If you create a secondary service or script to monitor for sshd running and restarting portreserve if it isn't, then it's once again a race.

Post reply on HN