Security through obscurity (or security by obscurity) is the reliance on the secrecy of the design, implementation, or configuration of a system as the primary mechanism of security. A system using security through obscurity assumes that its safety depends on attackers not knowing how the system works, rather than on the system being secure even when its design is fully known. The term is used predominantly as a criticism — an accusation that a security system's design is flawed because it cannot withstand analysis or an attack by a party who has learned how the system works.

Rejection as a primary mechanism

The security community consensus, codified in Kerckhoffs' principle (1883) and restated in Claude Shannon's maxim (1949) and in NIST guidance, holds that security through obscurity is not an acceptable primary security mechanism. A well-designed security system should remain secure even when everything about the system — except the specific cryptographic key or credential — is public knowledge. This does not mean that secrecy of implementation has no defensive value, only that a system that relies solely on implementation secrecy is inadequately secured: the moment the implementation becomes known, the security is gone entirely.

History

The debate over whether security systems should depend on secrecy of design is as old as professional security practice.

The Hobbs lock controversy (1851). At the Great Exhibition of 1851 in London, American locksmith Alfred Charles Hobbs publicly picked what were then considered the most secure locks available — the Bramah lock and the Chubb detector lock — demonstrating that their security rested in part on the obscurity of their mechanisms rather than on inherent resistance to picking. Hobbs's demonstration contributed to the principle that security mechanisms should remain secure even when their design is fully known and analyzed.

Kerckhoffs' principle and Shannon's maxim

Kerckhoffs' principle (1883). Auguste Kerckhoffs, a Dutch cryptographer, published a paper on military cryptography in the Journal des sciences militaires in which he stated that "a cryptosystem should be secure even if everything about the system, except the key, is public knowledge." This principle, now known as Kerckhoffs' principle, established the foundational premise of modern cryptographic design: the security of a cryptographic system should derive entirely from the secrecy of the key, not from the secrecy of the algorithm. A corollary is that algorithms should be published and subject to public analysis — the stronger the system proves to be after expert scrutiny, the higher the confidence in its security.

Shannon's maxim (1949). Claude Shannon reformulated Kerckhoffs' principle as "the enemy knows the system" in his 1949 paper "Communication Theory of Secrecy Systems." Shannon's formulation captures the operational reality of security design: a system designer must assume that adversaries will eventually learn the design of the system being protected, either through reverse engineering, insider information, or other means. Security that depends on adversaries not knowing the design is therefore fragile in exactly the situations in which security matters most.

Failures of obscurity in practice

Security through obscurity in practice. The history of security engineering provides numerous examples of systems whose designers relied on obscurity and subsequently failed when that obscurity was compromised: symmetric cipher designs that were thought proprietary until reverse-engineered, proprietary protocols whose security flaws became apparent only when they were analyzed, and physical security mechanisms whose vulnerabilities were unknown only because they had not been publicly studied.

NIST position

The US National Institute of Standards and Technology (NIST) states in its guidelines that "system security should not depend on the secrecy of the implementation or its components." NIST guidance distinguishes between using obscurity as a primary security mechanism (not acceptable) and using it as one layer in a defense-in-depth strategy (acceptable when not relied upon as the primary control).

This distinction is important in practice. NIST does not hold that secrecy of implementation has no value whatsoever — a system whose implementation is unknown to attackers is somewhat harder to attack than an identical system whose implementation is known — but rather that such obscurity should not be counted as a security control in the threat model. If the obscurity is stripped away, the system should still be secure.

Defense in depth

The accepted modern position is that security through obscurity may be used as one layer in a defense-in-depth strategy — a security architecture that does not depend on any single control but instead presents an attacker with multiple independent layers that must each be defeated. In such a strategy, obscurity of certain implementation details may slow an attacker or make attacks less convenient, but it is not the primary barrier. If every other control holds, the security of the system does not depend on the implementation being unknown.

Acceptable uses as a secondary layer

Examples of acceptable uses of obscurity as one defense layer include: changing default port numbers to reduce automated scanning noise (while relying on authentication and access controls for actual security), suppressing software version banners in HTTP responses to reduce targeted exploitation of known vulnerabilities (while relying on timely patching for actual security), and using non-standard protocols for internal communications (while relying on encryption and authentication for actual security).

In each case, the obscurity reduces the convenience of attacks but does not constitute the primary security control. A security model that depends on attackers not knowing the port number, the software version, or the internal protocol is a model that will fail when that information is discovered.

---

cites: application-programming-interface, virtual-appliance, computer-appliance