To me all these slogans around security is to ensure people really, truly, actually think about things before they go against the grain. Is using obscurity as part of your defence always wrong? No, but equally it often adds a false sense of security. Popularising these easy to remember slogans helps change peoples defaults. Nowadays, if someone sees an attempt at security by obscurity it (hopefully) rings alarm bells and causes them to interrogate it to ensure that there is also other security measures in place, or that it is otherwise OK. It's the same with "never roll your own crypto"
I find it somewhat interesting that the article uses an example which falls right into another pitfall that "security vs obscurity" is trying to prevent.
> SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised?
>
> Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. ... So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.
This is technically correct. However, the author has identified a security concern that he wants to mitigate: brute force attacks. Now, you could try and reduce that risk by using a different port which might reduce it by 50%, or* you could fix this issue by deploying fail2ban (or using ssh keys, or VPNs and bastion boxes, etc), and thus negating that attack vector entirely. There isn't even a usability argument here: making people remember the right port for ssh is less usable than setting up fail2ban. Of course there are tonnes of other attack vectors to consider, but in general where possible its better to "properly" (fsvo.) mitigate those concerns and only rely on obscurity where that isn't possible. If a concern is mitigated than adding obscurity does almost nothing, while likely proving to be more annoying to the end user (like in the case of specifying a port in the above example).
Now of course that's not to say that you should never use obscurity, but if you do then I think its entirely reasonable that you are prepared to give a good justification why its appropriate. For example, sharing via secret URLs is a good example where it can be easy to justify in some settings, but it equally may not be OK for documents that are really really sensitive as its relatively easy for links to be shared in error with the wrong people.
RE some comments about using obscurity to signal that your deployments would be harder to get into and thus for attackers to not bother: I'd genuinely love to know if that is true or not, I wouldn't be surprised if attackers assumed obfuscation mean that the more advance security measures hadn't been deployed (otherwise why bother with obfuscation?).
* Based on the twitter poll in TFA, though if you have a targeted attack it seems sensible to assume that if port 22 doesn't work they'd try again with other methods
I find it somewhat interesting that the article uses an example which falls right into another pitfall that "security vs obscurity" is trying to prevent.
> SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised? > > Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. ... So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.
This is technically correct. However, the author has identified a security concern that he wants to mitigate: brute force attacks. Now, you could try and reduce that risk by using a different port which might reduce it by 50%, or* you could fix this issue by deploying fail2ban (or using ssh keys, or VPNs and bastion boxes, etc), and thus negating that attack vector entirely. There isn't even a usability argument here: making people remember the right port for ssh is less usable than setting up fail2ban. Of course there are tonnes of other attack vectors to consider, but in general where possible its better to "properly" (fsvo.) mitigate those concerns and only rely on obscurity where that isn't possible. If a concern is mitigated than adding obscurity does almost nothing, while likely proving to be more annoying to the end user (like in the case of specifying a port in the above example).
Now of course that's not to say that you should never use obscurity, but if you do then I think its entirely reasonable that you are prepared to give a good justification why its appropriate. For example, sharing via secret URLs is a good example where it can be easy to justify in some settings, but it equally may not be OK for documents that are really really sensitive as its relatively easy for links to be shared in error with the wrong people.
RE some comments about using obscurity to signal that your deployments would be harder to get into and thus for attackers to not bother: I'd genuinely love to know if that is true or not, I wouldn't be surprised if attackers assumed obfuscation mean that the more advance security measures hadn't been deployed (otherwise why bother with obfuscation?).
* Based on the twitter poll in TFA, though if you have a targeted attack it seems sensible to assume that if port 22 doesn't work they'd try again with other methods