In defense of obscurity: why hiding implementation details still pays off

A common refrain in security forums—‘security through obscurity is bad’—gets the principle wrong. Kerckhoffs’s actual point was that systems shouldn’t rely solely on secrecy of design; obscurity layered on top of real controls is a legitimate defense-in-depth tactic that raises attacker cost. Time and compute are money, and dead ends push opportunistic attackers and bots toward easier targets.

The author backs this with concrete cases. A WordPress site running a vulnerable plugin in 2015 escaped a mass SQL-injection campaign because the default wp_ table prefix had been randomized—the off-the-shelf exploit script hit a missing-table error and moved on. Valve strips debug symbols from CS:GO binaries to slow cheat developers, and an accidental macOS release that shipped unstripped Mach-O symbols immediately accelerated cheat development until the build was pulled. Malware authors lean heavily on code obfuscation to frustrate analysts, and defenders like Google reCAPTCHA and Netflix DRM use the same technique to make bot automation and key extraction more expensive.

The AI counter-argument—that LLMs make obscurity trivial to defeat—misses the economics. Token costs and iteration time still favor the defender at scale; obscurity is a tax on the attacker, not a wall. The rule isn’t ‘never obscure,’ it’s ‘never depend only on obscurity.’