Weak Cryptographic Hash: User-Controlled PBE Salt

Potentially tainted user inputs should not be passed as the salt parameter to a Password-Based Key Derivation Function (PBKDF).

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source.

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

  string salt = ConfigurationManager.AppSettings["salt"];
  ...
  Rfc2898DeriveBytes rfc = new Rfc2898DeriveBytes("password", Encoding.ASCII.GetBytes(salt));
  ...
  

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the property salt. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Potentially tainted user inputs should not be passed as the salt parameter to a Password-Based Key Derivation Function (PBKDF).

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-controlled salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

    ...
    salt = getenv("SALT");
    PKCS5_PBKDF2_HMAC(pass, sizeof(pass), salt, sizeof(salt), ITERATION, EVP_sha512(), outputBytes, digest);
    ...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the environment variable SALT. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Potentially tainted user inputs should not be passed as the salt parameter to a Password-Based Key Derivation Function (PBKDF).

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

...
@property (strong, nonatomic) IBOutlet UITextField *inputTextField;
...
NSString *salt = _inputTextField.text;
const char *salt_cstr = [salt cStringUsingEncoding:NSUTF8StringEncoding];
...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     passwordLen,
                     salt_cstr,
                     salt.length,
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the text in the UITextField inputTextField. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Potentially tainted user inputs should not be passed as the salt parameter to a Password-Based Key Derivation Function (PBKDF).

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source.

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

function register(){
  $password = $_GET['password'];
  $username = $_GET['username'];
  $salt = getenv('SALT');

  $hash = hash_pbkdf2('sha256', $password, $salt, 100000);
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the environment variable SALT. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Potentially tainted user inputs should not be passed as the salt parameter to a Password-Based Key Derivation Function (PBKDF).

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source.

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']
  salt = os.environ['SALT']

  dk = hashlib.pbkdf2_hmac('sha256', password, salt, 100000)
  hash = binascii.hexlify(dk)
  store(username, hash)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the environment variable SALT. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Potentially tainted user inputs should not be passed as the salt parameter to a Password-Based Key Derivation Function (PBKDF).

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

...
salt=io.read
key = OpenSSL::PKCS5::pbkdf2_hmac(pass, salt, iter_count, 256, 'SHA256')
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the text in salt. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Potentially tainted user inputs should not be passed as the salt parameter to a Password-Based Key Derivation Function (PBKDF).

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

...
@IBOutlet weak var inputTextField : UITextField!
...
let salt = (inputTextField.text as NSString).dataUsingEncoding(NSUTF8StringEncoding)
let saltPointer = UnsafePointer<UInt8>(salt.bytes)
let saltLength = size_t(salt.length)
...
let algorithm : CCPBKDFAlgorithm = CCPBKDFAlgorithm(kCCPBKDF2)
let prf : CCPseudoRandomAlgorithm = CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256)
CCKeyDerivationPBKDF(algorithm,
                     passwordPointer,
                     passwordLength,
                     saltPointer,
                     saltLength,
                     prf,
                     100000,
                     derivedKeyPointer,
                     derivedKeyLength)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the text in the UITextField inputTextField. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.