4 ms·

The mantra "security by obscurity (is bad)" has been so oft repeated without context that the contextless "interpretation" become a false truism. The missing c

The mantra "security by obscurity (is bad)" has been so oft repeated without context that the contextless "interpretation" become a false truism. The missing context; "Security by (only) obscurity". Is not good security. Any single protection is not good security. Good security must include as many layers across as many axii as possible. Adding obscurity to your existing security stack / layers improves your security.

iso1631 6y ago
> Adding obscurity to your existing security stack / layers improves your security. In theory yes. In practice you are increasing the chance of someone else thinking "Oh this is secure I don't need to do that". I saw this very recently in several broadcasters all over the world - they have a broadcast server which comes with a well known default admin password for the webserver on port 80. Several of these blocked port 80 externally, but allowed another port (7071), as it said to do so in the manual. They then didn't bother changing the password because "port 80 is blocked". Had port 80 not been blocked they would have been more likely to think "Ooh I must change the password". Now it's not good they didn't change it anyway, but your flat statement that "Adding obscurity to your existing security stack / layers improves your security" only applies if nothing else in your security stack changes. I check port 22 on my public IP addresses to ensure that any servers are uptodate. Occasionally I'll find an out of date and yell at the department to fix it. That's far better than blocking port 22, as they then listen on port 2222 or similar, and never update their ssh servers, and then when someone does stumble across it, nobody has a clue it's happened. Never underestimate the ability for people to work around your "improved security" by introducing worse security problems
okennedy 6y ago
I mentioned this in another response, but I'll refine my argument here. Security by obscurity's negative connotation comes from the ratio of effort on the part of the system implementer to the effort on the part of the attacker. While it may take time to break into an "obscured" system, it also takes a lot of effort to build the system in the first place. Worse, if the security is broken, you have to re-implement from scratch. Better approaches decouple the implementation/methods for enforcing security from the random components of the system that need to be kept secret. Whether or not this increases the effort for the attacker, it drastically reduces the effort for the defender. If an RSA key is cracked, a new one can be generated in less than a second, and once deployed the attacker is back to square one. Having SSH on a different port adds the cost of a full port-scan to any attempt to break in, vs the cost of changing one line in a config file. That all being said, there is a major difference between changing your port number and changing your RSA key: The attacker/defender effort ratio scales linearly (vs exponentially). Every time you change your port number (a fixed cost), the attacker has to run another port scan (another fixed cost) to get past this layer. By contrast, the amount of effort needed to crack an RSA key is exponentially higher than the cost required to create a new one. However, adding a fixed port-scanning cost to each attack does actually correspond to a very high overhead for a non-targeted attack (their costs go up by ~2^16).

iso1631 6y ago

> Adding obscurity to your existing security stack / layers improves your security. In theory yes. In practice you are increasing the chance of someone else thinking "Oh this is secure I don't need to do that". I saw this very recently in several broadcasters all over the world - they have a broadcast server which comes with a well known default admin password for the webserver on port 80. Several of these blocked port 80 externally, but allowed another port (7071), as it said to do so in the manual. They then didn't bother changing the password because "port 80 is blocked". Had port 80 not been blocked they would have been more likely to think "Ooh I must change the password". Now it's not good they didn't change it anyway, but your flat statement that "Adding obscurity to your existing security stack / layers improves your security" only applies if nothing else in your security stack changes. I check port 22 on my public IP addresses to ensure that any servers are uptodate. Occasionally I'll find an out of date and yell at the department to fix it. That's far better than blocking port 22, as they then listen on port 2222 or similar, and never update their ssh servers, and then when someone does stumble across it, nobody has a clue it's happened. Never underestimate the ability for people to work around your "improved security" by introducing worse security problems

okennedy 6y ago

I mentioned this in another response, but I'll refine my argument here. Security by obscurity's negative connotation comes from the ratio of effort on the part of the system implementer to the effort on the part of the attacker. While it may take time to break into an "obscured" system, it also takes a lot of effort to build the system in the first place. Worse, if the security is broken, you have to re-implement from scratch. Better approaches decouple the implementation/methods for enforcing security from the random components of the system that need to be kept secret. Whether or not this increases the effort for the attacker, it drastically reduces the effort for the defender. If an RSA key is cracked, a new one can be generated in less than a second, and once deployed the attacker is back to square one. Having SSH on a different port adds the cost of a full port-scan to any attempt to break in, vs the cost of changing one line in a config file. That all being said, there is a major difference between changing your port number and changing your RSA key: The attacker/defender effort ratio scales linearly (vs exponentially). Every time you change your port number (a fixed cost), the attacker has to run another port scan (another fixed cost) to get past this layer. By contrast, the amount of effort needed to crack an RSA key is exponentially higher than the cost required to create a new one. However, adding a fixed port-scanning cost to each attack does actually correspond to a very high overhead for a non-targeted attack (their costs go up by ~2^16).