This article misses the point and makes a bunch of arguments that fall apart on anything more than the surface level... much like security through obscurity. W

This article misses the point and makes a bunch of arguments that fall apart on anything more than the surface level... much like security through obscurity. We'll look at the SSH port example. What does changing the port get you? You no longer get hit by the automated sweeping that hits basically all internet accessible IPs. Cool! So you had root/password or root/apple or whatever, you were going to get owned by the automated scans, good, you're now more secure. But you shouldn't have been using a weak password to begin with, and now there is a very real risk that you think you are more secure than you were previously. He compares this to animals that have natural camouflage, or the President switching cars in his convoy. But there's no guarantee that you will see an owl in a tree, or be able to determine which car the President is in. But you can scan every port on an IP and find sshd listening with fingerprinting. The cost there is basically zero for someone that wants to attack you. If all I had to do was wait a few seconds longer to make sure I saw an owl or know what car the President is in, then they would not be effective either. You cannot compare situations where there are specific limitations and use them as proof positive for a situation where those limitations don't exist. And this is important: His recommendation to run sshd on 64323 is also just actively making you LESS secure. Ports under 1024 are privileged on Linux - you must have superuser privileges or otherwise be granted access to bind to these ports. No such protections exist for 64323. Now, let's say you have a user level compromise on that server - they start a process monitoring to see if sshd ever restarts/crashes/otherwise stops listening on the port it was listening on, and as soon as it does, they start their own malicious sshd replacement. Now all it takes is someone ignoring the host key mismatch to give away their credentials, which the attack can then likely use to penetrate further into your environment. The author doesn't fully understand the add on effects of his suggestion here, and as a result one of his security by obscurity tips makes you less secure to a focused attacker. Meanwhile, if you REALLY wanted to secure SSH you do not make it listen on internet accessible IPs, and only have it available when you VPN in and access it via a jumphost while using key based auth with 2FA on top of it. When you start obfuscating your code, using random variable names, and generally making it harder to read, how much more likely are you to introduce bugs than you would with a clean code base? Are human introduced bugs more likely to be a security risk than variable names being random? Than code being obfuscated? I don't disagree with encrypting the database, but I also don't consider encryption or password/key protecting something security by obscurity. Basically: Obscuring things helps prevent you from low effort attackers that should not be scary to you to begin with. They do nothing to minimal amounts to protect you from dedicated attackers, and potentially introduce new risks that allow easier access from dedicated attackers. The sort of security measures you should be implementing to stop dedicated attackers will already eliminate the risk from the low effort attackers. NONE of the arguments in this article are new, and they have all been argued against quite extensively in the past.