Security through obscurity is not bad

Original Article ↗ Hacker News Discussion ↗

Security engineers are revisiting the old maxim that “security through obscurity is bad,” arguing that obscurity can be a useful supplemental layer even if it should never be the only defense. Commenters weigh benefits like reduced log noise, fewer automated attacks, and higher attacker effort against serious downsides such as complacency, loss of public scrutiny, added complexity, and fragile “black box” designs. Examples ranging from changing default WordPress table names or SSH ports to ASLR, port knocking, and obfuscated JavaScript illustrate how obscurity can either strengthen a defense‑in‑depth strategy or dangerously substitute for real hardening, especially as AI lowers the cost of large‑scale code analysis and exploitation.

What “security through obscurity” means (and semantic fights)

  • Many distinguish between:
    • “Security through obscurity” = security depends on hidden details → widely viewed as bad.
    • “Security including obscurity” = hidden details as one layer among others → mostly seen as fine.
  • Others argue the term is misleading: all security hides something (keys, passwords), so the phrase should be reserved for “relying on hidden mechanisms instead of robust controls.”
  • Kerckhoffs’s principle is frequently cited: design systems assuming the adversary knows everything except the secret keys.

Arguments that obscurity adds value

  • Reduces automated, low-skill attacks and log noise (e.g., moving SSH off port 22, changing WordPress login URL or table prefixes).
  • Higher signal-to-noise ratio can make real anomalies more detectable and reduce admin fatigue and SIEM cost.
  • Increases attacker effort for mass exploitation; opportunistic attackers may move on to easier targets.
  • Viewed as part of “defense in depth,” like hiding a safe behind a painting when the lock is already strong.
  • Examples cited: port knocking, JS obfuscation, CAPTCHAs, proprietary anti-cheat systems, randomized DB prefixes.

Arguments that obscurity is dangerous or overrated

  • Can create complacency: implementers stop short of “real” security (patching, auth, whitelisting).
  • Reduces public scrutiny; hidden designs may harbor flaws that never get reviewed.
  • Often provides trivial brute-force resistance (e.g., 16‑bit port space) compared to cryptographic keys.
  • Adds complexity, debugging pain, vendor lock-in, and operational overhead, especially in large organizations.
  • Some measures only “reduce noise” but do not materially improve security posture, yet get treated as if they do.

Examples and edge debates

  • SSH on nonstandard ports:
    • Pro: massive drop in random scans, easier monitoring.
    • Con: no intrinsic protection of SSH itself; IP whitelisting or VPNs considered stronger.
  • WordPress table prefix/login URL:
    • Pro: blocked commodity exploit scripts during a real plugin vuln.
    • Con: still not a substitute for patching and proper hardening.
  • ASLR and cryptography: disputed whether they count as “obscurity”; many emphasize they remain secure even when fully understood, because the keys, not the algorithms, are secret.

AI and changing threat models

  • Some claim AI makes de‑obfuscation cheap, eroding obscurity’s value.
  • Others respond that AI also raises defenders’ capabilities and that raising attacker “token costs” still matters.