Difference between revisions of "Avoid security by obscurity"

From OWASP
Jump to: navigation, search
(Related Controls)
(Related Vulnerabilities)
Line 28: Line 28:
 
* [[Hard-Coded Password]]
 
* [[Hard-Coded Password]]
 
* [[Password Management: Hardcoded Password]]
 
* [[Password Management: Hardcoded Password]]
* [[Plaintext Storage in Executable]]
 
 
  
 
==Related [[Controls]]==
 
==Related [[Controls]]==

Revision as of 21:49, 8 February 2009

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.



ASDR Table of Contents

Contents


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, but that the design or logic of the security control should be based on open and known principles. For example, in a cryptographic system, only the key should be required to remain secret (i.e., it should not rely on keeping the algorithm secret in order to remain secure).

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 hiding 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

TBD

References