Fair point! Obscurity as confusion is not what I had in mind, but your points on confusion are totally valid. Your analogy with predators works better here.

Using base64 encoding, or encrypting your database, are both examples in the article. While I agree base64 is super trivial, the point about either of these is defence in depth. In the language of the article, it's reducing likelihood of being compromised.

>If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port.

This is semantics. Personally I'd say if an attacker cannot sense anything to connect to, there is no "signal" you're sending. You're rather not sending a signal that you're a threat, as you're not sending a signal at all due to being functionally invisible. Otherwise, we could say literal nothingness is sending the same signal that your server is. We agree on the substance here, i.e. the obscurity increases the economic cost of hacking and works as a disincentive, so we may just agree to disagree on the semantics.

There is supposed to be a response when a port is closed telling you the machine is online but not listening to that port. https://en.wikipedia.org/wiki/Port_scanner

most people have firewalls configured to simply drop traffic not destined for open ports, in which case there is no response as the traffic never makes it beyond the firewall.

If you'd like to be very visible in a different way, you could always waste resources:

1. Endlessh: https://news.ycombinator.com/item?id=19465967

2. Tarbit: https://github.com/nhh/tarbit

“Security through obscurity” means something like e.g. “uses a bespoke unpublished crypto algorithm, in the hopes that nobody has put in the effort to exploit it yet.”

Usually this is a poor choice vs. going with the published industry standard, because crypto is hard to get right, and people rolling their own implementations usually screw it up, making life much easier for dedicated attackers than trying to attack something that people have been trying and failing to breach for years or decades.

Software makers for example typically don’t publish the technical details of their anti-piracy code. But this usually doesn’t prevent software that people care about from being “cracked” quickly after release.

Banking Software uses all sorts of security through obscurity. Infact Unisys used to make custom 48bit CPUs for their clearpath OS to make targeting the hardware very difficult without inside knowledge of the chip architecture.

You are making the same argument this article is trying to explain to you. Security by Obscurity is not bad because _on its own_ its not enough, its good because coupled with other layers it adds security. I have been told to remove security by obscurity layers from systems by people that don't grok this. Security was, in a few cases, reduced to nothing. Systems that have one industry standard approach only laid totally open on the Internet due to a single misconfiguration or a single CVE being published. Any other layer would have helped, however "insecure", but they were removed due to the misconception that the layers themselves were "insecure". I would go so far as to say the first layer should always be security by obscurity for any unique system. If you fire up a web server and have the first security requirement that each http request must have the header X-Wibble:wobble I promise you this layer of security will be working hard all day long. Cheap, impossible to get wrong, it's not sufficient but it works.