In cryptography, a "salt" is an extra piece of data which is included when hashing a password. This makes rainbow-table attacks more difficult. Using a cryptographic hash function without an unpredictable salt increases the likelihood that an attacker could successfully find the hash value in databases of precomputed hashes (called rainbow-tables).

This rule raises an issue when a hashing function which has been specifically designed for hashing passwords, such as PBKDF2, is used with a non-random, reused or too short salt value. It does not raise an issue on base hashing algorithms such as sha1 or md5 as they should not be used to hash passwords.

Recommended Secure Coding Practices

• Use hashing functions generating their own secure salt or generate a secure random value of at least 16 bytes.
• The salt should be unique by user password.

Noncompliant Code Example

public void Hash(string password)
{
    var salt = Encoding.UTF8.GetBytes("Hardcoded salt");
    var fromHardcoded = new Rfc2898DeriveBytes(password, salt);     // Noncompliant, salt is hardcoded

    salt = Encoding.UTF8.GetBytes(password);
    var fromPassword = new Rfc2898DeriveBytes(password, salt);     // Noncompliant, password should not be used as a salt as it makes it predictable

    var shortSalt = new byte[8];
    RandomNumberGenerator.Create().GetBytes(shortSalt);
    var fromShort = new Rfc2898DeriveBytes(password, shortSalt);   // Noncompliant, salt is too short (should be at least 16 bytes, not 8)
}

Compliant Solution

public DeriveBytes Hash(string password)
{
    return new Rfc2898DeriveBytes(password, 16);
}

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-759 - Use of a One-Way Hash without a Salt
• MITRE, CWE-760 - Use of a One-Way Hash with a Predictable Salt
• SANS Top 25 - Porous Defenses