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

CWE-759: Use of a One-Way Hash without a Salt

 
Use of a One-Way Hash without a Salt
Weakness ID: 759 (Weakness Class)Status: Incomplete
+ Description

Description Summary

The software uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the software does not also use a salt as part of the input.

Extended Description

This makes it easier for attackers to pre-compute the hash value using dictionary attack techniques such as rainbow tables.

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism; Gain privileges / assume identity

If an attacker can gain access to the hashes, then the lack of a salt makes it easier to conduct brute force attacks using techniques such as rainbow tables.

+ Demonstrative Examples

Example 1

In this example, a new user provides a new username and password to create an account. The program hashes the new user's password then stores it in a database.

(Bad Code)
Example Language: Python 
def storePassword(userName,Password):
hasher = hashlib.new('md5')
hasher.update(Password)
hashedPassword = hasher.digest()
# UpdateUserLogin returns True on success, False otherwise
return updateUserLogin(userName,hashedPassword)

While it is good to avoid storing a cleartext password, the program does not provide a salt to the hashing function, thus increasing the chances of an attacker being able to reverse the hash and discover the original password if the database is compromised.

Fixing this is as simple as providing a salt to the hashing function on initialization:

(Good Code)
Example Language: Python 
def storePassword(userName,Password):
hasher = hashlib.new('md5',b'SaltGoesHere')
hasher.update(Password)
hashedPassword = hasher.digest()
# UpdateUserLogin returns True on success, False otherwise
return updateUserLogin(userName,hashedPassword)

Note that regardless of the usage of a salt, the md5 hash is no longer considered secure, so this example still exhibits CWE-327.

+ Observed Examples
ReferenceDescription
CVE-2008-1526Router does not use a salt with a hash, making it easier to crack passwords.
CVE-2006-1058Router does not use a salt with a hash, making it easier to crack passwords.
+ Potential Mitigations

Phase: Architecture and Design

Generate a random salt each time you process a new password. Add the salt to the plaintext password before hashing it. When you store the hash, also store the salt. Do not use the same salt for every password that you process (CWE-760). [R.759.3]

Phase: Architecture and Design

Use one-way hashing techniques that allow you to configure a large number of rounds, such as bcrypt. This may increase the expense when processing incoming authentication requests, but if the hashed passwords are ever stolen, it significantly increases the effort for conducting a brute force attack, including rainbow tables. With the ability to configure the number of rounds, you can increase the number of rounds whenever CPU speeds or attack techniques become more efficient.

Phases: Implementation; Architecture and Design

When you use industry-approved techniques, you need to use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.

+ Background Details

In cryptography, salt refers to some random addition of data to an input before hashing to make dictionary attacks more difficult.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base327Use of a Broken or Risky Cryptographic Algorithm
Research Concepts (primary)1000
ChildOfCategoryCategory816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory8662011 Top 25 - Porous Defenses
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory903SFP Cluster: Cryptography
Software Fault Pattern (SFP) Clusters (primary)888
+ References
[R.759.1] Robert Graham. "The Importance of Being Canonical". 2009-02-02. <http://erratasec.blogspot.com/2009/02/importance-of-being-canonical.html>.
[R.759.2] Thomas Ptacek. "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes". 2007-09-10. <http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html>.
[R.759.3] James McGlinn. "Password Hashing". <http://phpsec.org/articles/2005/password-hashing.html>.
[R.759.4] Jeff Atwood. "Rainbow Hash Cracking". 2007-09-08. <http://www.codinghorror.com/blog/archives/000949.html>.
[R.759.5] "Rainbow table". Wikipedia. 2009-03-03. <http://en.wikipedia.org/wiki/Rainbow_table>.
[R.759.6] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "Creating a Salted Hash" Page 302. 2nd Edition. Microsoft. 2002.
[R.759.7] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Salt Values", Page 46.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-03-03Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2009-10-29CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated References
2011-03-29CWE Content TeamMITREInternal
updated Observed_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations, Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITREInternal
updated References, Related_Attack_Patterns, Relationships
Page Last Updated: May 14, 2012