CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.10)  
ID

CWE-656: Reliance on Security Through Obscurity

Weakness ID: 656
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.

Extended Description

This reliance on "security through obscurity" can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection.

+ Alternate Terms
Never Assuming your secrets are safe
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability
Other

Technical Impact: Other

The security mechanism can be bypassed easily.

+ Demonstrative Examples

Example 1

The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077. If ISNs can be guessed (due to predictability, CWE-330) or sniffed (due to lack of encryption, CWE-311), then an attacker can hijack or spoof connections. Many TCP implementations have had variations of this problem over the years, including CVE-2004-0641, CVE-2002-1463, CVE-2001-0751, CVE-2001-0328, CVE-2001-0288, CVE-2001-0163, CVE-2001-0162, CVE-2000-0916, and CVE-2000-0328.

Example 1 References:

Jon Postel, Editor. "RFC: 793, TRANSMISSION CONTROL PROTOCOL". Information Sciences Institute. September 1981. <http://www.ietf.org/rfc/rfc0793.txt>.
+ Observed Examples
ReferenceDescription
Reliance on hidden form fields in a web application. Many web application vulnerabilities exist because the developer did not consider that "hidden" form fields can be processed using a modified client.
Hard-coded cryptographic key stored in executable program.
Hard-coded cryptographic key stored in executable program.
Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
+ Potential Mitigations

Phase: Architecture and Design

Always consider whether knowledge of your code or design is sufficient to break it. Reverse engineering is a highly successful discipline, and financially feasible for motivated adversaries. Black-box techniques are established for binary analysis of executables that use obfuscation, runtime analysis of proprietary protocols, inferring file formats, and others.

Phase: Architecture and Design

When available, use publicly-vetted algorithms and procedures, as these are more likely to undergo more extensive security analysis and testing. This is especially the case with encryption and authentication.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Development Concepts699
ChildOfWeakness ClassWeakness Class657Violation of Secure Design Principles
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts1000
ChildOfCategoryCategory975SFP Secondary Cluster: Architecture
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base259Use of Hard-coded Password
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base321Use of Hard-coded Cryptographic Key
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base472External Control of Assumed-Immutable Web Parameter
Research Concepts1000
+ Relationship Notes

Note that there is a close relationship between this weakness and CWE-603 (Use of Client-Side Authentication). If developers do not believe that a user can reverse engineer a client, then they are more likely to choose client-side authentication in the belief that it is safe.

+ Causal Nature

Implicit

+ References
Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. September, 1975. <http://web.mit.edu/Saltzer/www/publications/protection/>.
Sean Barnum and Michael Gegick. "Never Assuming that Your Secrets Are Safe". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/352.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-01-18Pascal MeunierPurdue UniversityExternal Submission
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Weakness_Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Description, Name
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Reliance on Security through Obscurity

More information is available — Please select a different filter.
Page Last Updated: January 11, 2017