Reliance on Security through Obscurity
Weakness ID: 656 (Weakness Base)Status: Draft
+ 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

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
CVE-2006-6588Reliance 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.
CVE-2006-7142Hard-coded cryptographic key stored in executable program.
CVE-2005-4002Hard-coded cryptographic key stored in executable program.
CVE-2006-4068Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
+ Potential Mitigations

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.

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.

+ Other 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.

+ 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
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
+ 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
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Reliance on Security through Obscurity
Back to top