Use of a One-Way Hash without a Salt| ID: 759 | Date: (C)2012-05-14 (M)2022-10-10 |
| Type: weakness | Status: INCOMPLETE |
| Abstraction Type: Class |
Description
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 DescriptionThis makes it easier for attackers to pre-compute the hash value using
dictionary attack techniques such as rainbow tables.
Applicable PlatformsNone
Related Attack Patterns
Common Consequences
| Scope | Technical Impact | Notes |
|---|
| Access_Control | Bypass protection
mechanismGain 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. |
Detection MethodsNone
Potential Mitigations
| Phase | Strategy | Description | Effectiveness | Notes |
|---|
| 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. | High | |
| Architecture and Design | | If a technique that uses stretching cannot be implemented, then
generate a random salt each time a new password is processed. Add the
salt to the plaintext password before hashing it. When storing the hash,
also store the salt. Do not use the same salt for every password
(CWE-760). [R.759.3] | Moderate | |
| ImplementationArchitecture and Design | | When using industry-approved techniques, use them correctly. Don't cut
corners by skipping resource-intensive steps (CWE-325). These steps are
often essential for preventing common attacks. | | |
Relationships
| Related CWE | Type | View | Chain |
|---|
| CWE-759 ChildOf CWE-903 | Category | CWE-888 | |
Demonstrative Examples (Details)
- In both of these examples, a user is logged in if their given
password matches a stored password: (Demonstrative Example Id DX-101)
- 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.
Observed Examples
- CVE-2008-1526 : Router does not use a salt with a hash, making it easier to crack passwords.
- CVE-2006-1058 : Router does not use a salt with a hash, making it easier to crack passwords.
For more examples, refer to CVE relations in the bottom box.
White Box Definitions None
Black Box Definitions None
Taxynomy MappingsNone
References:
- Robert Graham .The Importance of Being Canonical. 2009-02-02.
- Thomas Ptacek .Enough With The Rainbow Tables: What You Need To Know About
Secure Password Schemes. 2007-09-10.
- James McGlinn .Password Hashing.
- Jeff Atwood .Rainbow Hash Cracking. 2007-09-08.
- .Rainbow table. Wikipedia. 2009-03-03.
- M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 9, "Creating a Salted Hash" Page
302'. Published on 2002.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 2, "Salt Values", Page 46.'. Published on 2006.
- B. Kaliski .RFC2898 - PKCS #5: Password-Based Cryptography Specification
Version 2.0. Published on 2000.
- Coda Hale .How To Safely Store A Password. 2010-01-31.
- Colin Percival .Tarsnap - The scrypt key derivation function and encryption
utility.
- Brian Krebs .How Companies Can Beef Up Password Security (interview with
Thomas H. Ptacek). 2012-06-11.
- Solar Designer .Password security: past, present, future. Published on 2012.
- Troy Hunt .Our password hashing has no clothes. 2012-06-26.
- Joshbw .Should we really use bcrypt/scrypt?. 2012-06-08.
