CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

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.7)  

Presentation Filter:

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

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:
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
Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
+ Potential Mitigations

Phase: Architecture and Design

Use an adaptive 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 compared to intentionally-fast functions such as MD5. 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 [R.328.1], scrypt [R.328.2], and PBKDF2 [R.328.3]. 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

+ 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
ChildOfCategoryCategory934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
Weaknesses in OWASP Top Ten (2013) (primary)928
+ 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.
[R.328.1] [REF-45] Johnny Shelley. "bcrypt". <http://bcrypt.sourceforge.net/>.
[R.328.2] [REF-39] Colin Percival. "Tarsnap - The scrypt key derivation function and encryption utility". <http://www.tarsnap.com/scrypt.html>.
[R.328.3] [REF-40] B. Kaliski. "RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0". 5.2 PBKDF2. 2000. <http://tools.ietf.org/html/rfc2898>.
[REF-38] Coda Hale. "How To Safely Store A Password". 2010-01-31. <http://codahale.com/how-to-safely-store-a-password/>.
[REF-41] 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/>.
[REF-42] Solar Designer. "Password security: past, present, future". 2012. <http://www.openwall.com/presentations/PHDays2012-Password-Security/>.
[REF-43] Troy Hunt. "Our password hashing has no clothes". 2012-06-26. <http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html>.
[REF-44] 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
Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08MITREInternal
updated Relationships, Observed_Example, Taxonomy_Mappings
2008-10-14MITREInternal
updated Description
2009-01-12MITREInternal
updated Description, References
2009-10-29MITREInternal
updated Relationships
2011-06-01MITREInternal
updated Common_Consequences
2012-05-11MITREInternal
updated References, Related_Attack_Patterns, Relationships
2012-10-30MITREInternal
updated Demonstrative_Examples, Potential_Mitigations, References
2014-02-18MITREInternal
updated Potential_Mitigations, References
2014-06-23MITREInternal
updated Relationships
Page Last Updated: June 23, 2014