Security through obscurity is the practice of relying on the secrecy of a system’s design or implementation, rather than on sound security controls, to protect it from attack.
What security through obscurity means
Typical examples are proprietary encryption algorithms kept secret, admin panels hidden at unusual URLs, services moved to non-standard ports, undocumented network protocols or passwords “protected” only by being stored in an unexpected place. The assumption is that attackers will not find out how the system works.
Why it fails as the main defence
The idea was rejected in cryptography as early as 1883 by Kerckhoffs’s principle: a system should remain secure even if everything about it except the key is public. Claude Shannon later summarised it as “the enemy knows the system”. NIST guidance on server security likewise states that system security should not depend on the secrecy of the implementation. Real cases confirm it:
- the secret CSS encryption on DVDs was broken in 1999 (DeCSS);
- the proprietary Crypto-1 cipher of MIFARE Classic transit and access cards was reverse-engineered and broken in 2008;
- hidden services on unusual ports are found within minutes by mass port scanning tools such as Masscan and search engines like Shodan.
Firmware and closed-source software can always be analysed through reverse engineering, so secrecy only delays a determined attacker. Worse, it prevents independent review that would find weaknesses earlier.
Where obscurity is acceptable
Obscurity is not useless as an extra layer. Moving SSH to another port reduces noise from automated bots, and not revealing software versions makes attackers’ work slightly harder. The rule of thumb: obscurity may complement real controls such as strong authentication, patching and encryption based on public, well-studied algorithms, but must never replace them.
