> In this post, I will raise my objection against the idea of “Security by obscurity is bad”.
I think this article's fundamental flaw is that it conflates the concepts of obscurity and a secret.
To start with, a definition: a system is secure if an attacker has no reasonable chance of unauthorized access over a relevant period unless they are in possession of necessary secrets.
SSH with public-key authentication is secure by this definition, since the (remote) attacker has no realistic chance of guessing the proper secret key within a human lifetime and there is no better-than-chance way to obtain the secret key. Likewise, a strong, high-entropy password is impractical to guess.
Running on nonstandard ports, however? It doesn't add practical security because guessing is so trivial. The author's twitter reach had a 50/50 split on whether they scanned all ports for pen-testing, so that implies that using a nonstandard port increases the time-to-compromise from either (lifetime of the universe) or (about an hour) to twice that, depending on whether the second (real) layer of security is vulnerable. In neither case does the obscure port provide meaningful protection.
Some activities like port-knocking can add security, but only if the practitioner thinks of the knocking as a secret from the start. That requires:
* Limiting who has knowledge of the secret (i.e.: a port knocking routine known only to you is secret; one distributed in a public client for access to a production service is not),
* Having plans in place to change the secret if it is ever compromised (DeCSS) or found to be flawed, and
* Ideally ensuring that the secret cannot be guessed / confirmed independently of other secrets.
Other suggestions in the article ignore this difference:
* Database encryption requires an attacker to possess two secrets for extraction (internal access to the database plus the key) rather than just one. It's not obscurity.
* Randomizing variable names or obfuscating code is not a secret because an interested attacker can reverse the obfuscation with ordinary human levels of effort. The confidence here is strictly false, since it "secures" against low-effort attackers and not high-effort ones. The "secret" is distributed publicly, so it is no secret at all.
* The convoy example is again a secret; the point is that a would-be attacker does not know which car contains the target and has no reasonable ability to guess with better-than-chance success.
Obscurity goes from marginally effective (or outright ineffective) to counterproductive when its implementation makes it harder for the designer to reason about their own system. Someone who rolls their totally unique cryptosystem is relying in part on algorithmic obscurity for their security, but in doing so they give up on established (and battle-tested) best practices in favour of their own limited analysis.
Ultimately, the "Swiss cheese" model of security is a poor analogy because a big number for a human is a small number for a computer. To take the convoy analogy again, a would-be attacker is only going to get one shot, but a computer can try billions.