CWE
CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.4)  

CWE-328: Reversible One-Way Hash

 
Reversible One-Way Hash
Weakness ID: 328 (Weakness Base)Status: Draft
+ Description

Description Summary

The product uses a hashing algorithm that produces a hash value that can be used to determine the original input, or to find an input that can produce the same hash, more efficiently than brute force techniques.

Extended Description

This weakness is especially dangerous when the hash is used in security algorithms that require the one-way property to hold. For example, if an authentication system takes an incoming password and generates a hash, then compares the hash to another hash that it has stored in its authentication database, then the ability to create a collision could allow an attacker to provide an alternate password that produces the same target hash, bypassing authentication.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Demonstrative Examples

Example 1

In both of these examples, a user is logged in if their given password matches a stored password:

(Bad Code)
Example Language: C 
unsigned char *check_passwd(char *plaintext) {
ctext = simple_digest("sha1",plaintext,strlen(plaintext), ... );
//Login if hash matches stored hash
if (equal(ctext, secret_password())) {
login_user();
}
}
(Bad Code)
Example Language: Java 
String plainText = new String(plainTextIn);
MessageDigest encer = MessageDigest.getInstance("SHA");
encer.update(plainTextIn);
byte[] digest = password.digest();
//Login if hash matches stored hash
if (equal(digest,secret_password())) {
login_user();
}

This code uses the SHA-1 hash on user passwords, but the SHA-1 algorithm is no longer considered secure. Note this code also exhibits CWE-759 (Use of a One-Way Hash without a Salt).

+ Observed Examples
ReferenceDescription
CVE-2006-4068Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
+ Potential Mitigations

Phase: Architecture and Design

Use a cryptographic hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack, far more than standards such as MD5, which are intentionally designed to be fast. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.

Some hash functions that have one or more of these desired properties include bcrypt, scrypt, and PBKDF2. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.

Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.

Effectiveness: High

Phase: Architecture and Design

Use a hash algorithm that is currently considered to be strong by experts in the field. MD-4 and MD-5 have known weaknesses. SHA-1 has also been broken.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory310Cryptographic Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class326Inadequate Encryption Strength
Research Concepts1000
ChildOfWeakness BaseWeakness Base327Use of a Broken or Risky Cryptographic Algorithm
Research Concepts (primary)1000
ChildOfCategoryCategory903SFP Cluster: Cryptography
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERReversible One-Way Hash
+ References
Alexander Sotirov et al.. "MD5 considered harmful today". <http://www.phreedom.org/research/rogue-ca/>.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Integrity", Page 47.. 1st Edition. Addison Wesley. 2006.
B. Kaliski. "RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0". 2000. <http://tools.ietf.org/html/rfc2898>.
Coda Hale. "How To Safely Store A Password". 2010-01-31. <http://codahale.com/how-to-safely-store-a-password/>.
Colin Percival. "Tarsnap - The scrypt key derivation function and encryption utility". <http://www.tarsnap.com/scrypt.html>.
Brian Krebs. "How Companies Can Beef Up Password Security (interview with Thomas H. Ptacek)". 2012-06-11. <http://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/>.
Solar Designer. "Password security: past, present, future". 2012. <http://www.openwall.com/presentations/PHDays2012-Password-Security/>.
Troy Hunt. "Our password hashing has no clothes". 2012-06-26. <http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html>.
Joshbw. "Should we really use bcrypt/scrypt?". 2012-06-08. <http://www.analyticalengine.net/2012/06/should-we-really-use-bcryptscrypt/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Observed_Example, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-01-12CWE Content TeamMITREInternal
updated Description, References
2009-10-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations, References
Back to top
Page Last Updated: February 20, 2013
 

CWE is co-sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security.

This Web site is sponsored and managed by The MITRE Corporation to enable stakeholder collaboration. Copyright © 2006-2013, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Contact cwe@mitre.org for more information.
Privacy policy
Terms of use
Contact us