Security Through Obscurity Is Not Security, Digital Hygiene Is

I held the same position for years and I defended it fiercely in a comment in April 2020:

Security through obscurity is not security. At best it buys time, at worst it costs you some. On top of that it completely distorts the trust relationship and the reliability of the said security. Avoid it…

And to illustrate the absurdity, I followed up with the recipe: don’t share your sources, don’t share your specs, obfuscate your code, encrypt it in memory, delay its execution, make it polymorphic, fetch your payload remotely… wait… are we talking about malware here?

That catalogue is literally the malware evasion playbook. When the countermeasures you recommend are indistinguishable from those of malware, you have a definition problem.

But in November 2025, in a discussion about the public exposure of information, I corrected my own categorical habit: I would avoid calling it security through obscurity here and rather call it digital hygiene. This article is the story of that ground shift and of what remains of the question once you stop caricaturing it.

What obscurity does not do

The founding reproach still stands. A security model that relies on the secrecy of its mechanism:

• Only delays a motivated attacker. An automated scan crosses a port change in minutes. A port knock sniffed once is replayed forever.
• Distorts the trust relationship. The “protection” creates the illusion of being covered, the admin stops hardening what actually matters. That is the worst effect: obscurity degrades the reliability of everything else.
• Turns against you. The secret mechanism becomes one more attack surface. When it breaks, you are locked out of your own server.

Lived example: port knocking . In the 2000s I used it, even a homegrown variant based only on TCP flags on usually unfiltered ports (80, 443…), varying with a time-based parameter to avoid the sniffable, replayable side. I liked it, I caused colleagues hours of debugging and I now recognize it for what it was: security through obscurity, with one more operational layer to maintain. The sequence is sniffable, replayable and the day the firewall rule and the knock rule diverge, you lock yourself out.

SPA (Single Packet Authorization, fwknop) fixed the crypto part: one authenticated, non-replayable packet. It was better. It was also one more operational layer, for an effect WireGuard now gives natively, but more on that later.

Same verdict for the eternal port 22 debate. Moving SSH only slows a real attack down: aside from automated scans and firewalling bypass, it serves nothing but self-comfort. Multiplexing 22 with SSLH on 443, an idea I experimented with and will happily file under seductive bad ideas: flux readability and debugging lose half the time.

What Kerckhoffs does not cover

So should we throw out obscurity entirely? No and that is where the 2025 nuance lands.

Kerckhoffs’ principle states that the security of a cryptographic system must rest only on the secrecy of the key, not of the system. It is fundamental, but its domain is cryptography. It does not extend to every field.

A trivial counter-example: a photo posted on social media allows, with relatively little effort, recovering information ranging from plain geolocation to the cloning of physical door keys, through the identification of people, places and habits. We are no longer in an encryption problem: we are in an information exposure problem. Kerckhoffs says nothing about how much public information you dump on yourself.

Another counter-example: the resource triangle. My password, my SSH key, my access code: three different things, whose compromise has different consequences and whose rotation has different costs. Treating them as a single “secret” on the pretext that Kerckhoffs talks about keys is confusing crypto with hygiene.

The right principle here is simpler and older than Kerckhoffs: do not expose information needlessly. The controlled introduction of obscurity or randomness into public information tends to reduce the exposure surface and the predictability of targets. Not as defense, as hygiene.

The example that sums it all up: the invisible open port

Take the original need of port knocking: “I don’t want my service to be visible”. In 2000, the answer was a sequence of ports. In 2026, the answer fits in one sentence: a WireGuard server silently ignores every unauthenticated packet. Same invisibility effect, real crypto, no extra operational layer, kernel-space and fast.

WireGuard does not hide its existence from an attacker who knows the protocol, granted. But it answers nobody but its peers: no banner, no application fingerprint, no attempt logs to monitor. The “slowing down” that port knocking promised becomes a refusal by construction.

For mesh or direct peering, WireGuard is simple to deploy and fast. In enterprises you still find plenty of IPSec (Site-to-Site where Fortinet/Cisco/Stormshield interoperability is non-negotiable) and OpenVPN (client-to-site where TCP fallback and flexible routing matter). But the pattern stands: where an obscurity layer added a fragile mechanism, correct design (authentication by default, silence on failure) produces the same effect without the debt.

Same logic for the emergency use: portknocking/SPA, when I keep it, is only as a break-glass mechanism, in case of a failure that prevents me from going through anything else, before having to crawl to the console via the provider’s KVMoIP or IPMI. A documented plan B, not a strategy.

Digital hygiene: the right name

What the old “obscurity yes/no” debate misses is that the question has two distinct layers:

1. The mechanism: encryption, access control, authentication. Here Kerckhoffs applies, obscurity as the only layer is an anti-pattern, end of debate.
2. The exposure: what your metadata, your screenshots, your repository lists, your profiles and your photos tell about you and your infrastructure. Nobody here demands an algorithmic secret: we ask for mastery of public information.

The second layer has no glamorous technical name. Attackers call it OSINT, defenders call it digital hygiene. The principle of least exposure: publish only what has a reason to be published, perturb what is published needlessly and consider that every public bit is already in a training corpus or a search index.

Obscurity has a place there, complementary to security by design, exactly like curtains complement a lock: they do not stop break-ins, they reduce what the passer-by knows about your interior. Confusing it with a defense layer is the malware recipe. Banning it from the palette on the pretext of “security through obscurity” is confusing mechanism design with exposure management.

Summary

• Security through obscurity is not a strategy: it delays, distorts trust and turns against you. The comparison with the malware toolbox is not a joke, it is a diagnosis.
• Kerckhoffs applies to cryptographic mechanisms, not to public information management. Not exposing needlessly is a hygiene principle, not obscurity.
• Most historical needs of port knocking and port moving are covered natively by correct design: WireGuard silently ignores anything unauthenticated.
• Mastery and perturbation of public information are part of modern digital hygiene. Not a strategy, a daily discipline.