Avoid security by obscurity

From OWASP
Revision as of 10:29, 26 May 2008 by Cduffey346 (Talk | contribs)

Jump to: navigation, search

This is a principle or a set of principles. To view all principles, please see the Principle Category page.

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


Description

Security through obscurity is the reliance on the secrecy of the implementation of a system or components of a system to keep it secure. Security though obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of critical systems should not be reliant upon keeping details hidden.


Examples

Obscurity Through Alternate Port Bindings

Using an alternate port number for an otherwise insecure network service (e.g., Telnet listening on port 1025) as a method of hidding the fact that the service is listening on the server is an ineffective security control. Most network scanners would easily fingerprint the service on that alternate port number. Instead, a known secure network service should be used like Secure Shell (SSH).

Obscurity Through Closed Source Code

The security of an application should not rely upon knowledge of the source code being kept secret. Hiding things like hard-coded passwords and otherwise vulnerable code by not releasing the source code is a poor security control (see the Assume attackers have source code Principle for more information). The security should instead rely on a well understood and open design including reasonable password policies, defense in depth, business transaction limits, solid network architecture, and fraud and audit controls. A practical counter-example to relying on obscurity of source code as a security control is Linux. Linux’s source code is widely available, and yet when properly secured, Linux is a hardy, secure and robust operating system.


Related Vulnerabilities


Related Controls


References