salt 值应使用加密伪随机数值生成器来创建。如果不使用随机 salt 值，则结果散列或 HMAC 的可预测性会高得多，也更容易受到字典式攻击。

示例 1：以下代码重新使用密码作为 salt：

...
let password = getPassword();
let salt = password;
crypto.pbkdf2(
    password,
    salt,
    iterations,
    keyLength,
    "sha256",
    function (err, derivedKey) { ... }
);

salt 值应使用加密伪随机数值生成器来创建。如果不使用随机 salt 值，则结果散列或 HMAC 的可预测性会高得多，也更容易受到字典式攻击。

示例 1：以下代码重新使用密码作为 salt：

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

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

salt 值应使用加密伪随机数值生成器来创建。如果不使用随机 salt 值，则结果散列或 HMAC 的可预测性会高得多，也更容易受到字典式攻击。

例 1：以下代码重新使用密码作为 salt：

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']

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

salt 值应使用加密伪随机数值生成器来创建。如果不使用随机 salt 值，则结果散列或 HMAC 的可预测性会高得多，也更容易受到字典式攻击。

例 1：以下代码重新使用密码作为 salt：

require 'openssl'
...
req = Rack::Response.new
password = req.params['password']
...
key = OpenSSL::PKCS5::pbkdf2_hmac(password, password, 100000, 256, 'SHA256')
...

弱加密散列值：用户控制算法问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据用于指定加密散列算法。

如同许多软件安全漏洞一样，弱加密散列值：用户控制算法只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，这些数据随后用于指定加密散列算法。攻击者可以指定一个存在已知缺陷的散列算法（比如 MD5），以破坏应用程序数据的完整性和安全性。

示例 1：以下代码使用了用户控制算法：

    ...
    string hashname = ConfigurationManager.AppSettings["hash"];
    ...
    HashAlgorithm ha = HashAlgorithm.Create(hashname);
    ...

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 hash 属性来操纵散列算法。一旦程序发布，撤消与用户控制的算法相关的问题就会非常困难，因为很难知道恶意用户是否确定了特定加密散列的算法参数。

在以下情况下会发生 Weak Cryptographic Hash:用户控制算法问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据用于指定加密散列算法。

如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制算法是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，该数据随后用于指定加密散列算法。攻击者可以指定一个存在已知缺陷的散列算法（比如 MD5），以破坏应用程序数据的完整性和安全性。

例 1： 下列代码使用了用户控制算法：

require 'openssl'
require 'csv'
...
CSV.read(my_file).each do |row|
  ...
  hash = row[4]
  ...
  digest = OpenSSL::Digest.new(hash, data)
  ...
end

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 CSV 文件中的 hash 来操纵散列算法。一旦程序发布，撤消与用户控制的算法相关的问题就会非常困难，因为很难知道恶意用户是否确定了特定加密散列的算法参数。

弱加密散列值：用户控制 PBE Salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序。

2. 用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数中的 salt 使用。


如同许多软件安全漏洞一样，弱加密散列值：用户控制 PBE Salt 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PBKDF 中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1. 攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

示例 1：以下代码使用了用户控制 salt：

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

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 salt 属性来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash:用户控制 PBE 的 Salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数中的 salt 使用。


如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制 PBE 的 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PSKDF 中的全部或部分 salt。

用户控制 salt 的问题在于，它可以实现几个不同的攻击：

1. 攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

例 1： 以下代码使用用户控制 salt：

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

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改环境变量 SALT 来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash: 用户控制的 PBE salt 问题将在以下情况下出现：

1.数据通过一个不可信赖的数据源进入程序

2.用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数 (PBKDF) 中的 salt 使用。


如同许多软件安全漏洞一样，Weak Cryptographic Hash: 用户控制的 PBE salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PSKDF 中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1.攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2.如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

示例 1：以下代码会使用用户控制的 salt：

app.get('/pbkdf2', function(req, res) {
    ...
    let salt = req.params['salt'];
    crypto.pbkdf2(
        password,
        salt,
        iterations,
        keyLength,
        "sha256",
        function (err, derivedKey) { ... }
    );
}

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 salt 属性来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

弱加密散列值：用户控制 PBE Salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数中的 salt 使用。


如同许多软件安全漏洞一样，弱加密散列值：用户控制 PBE Salt 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PBKDF 中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1. 攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

示例 1：以下代码会使用用户控制的 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);
...

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 UITextField inputTextField 中的文本来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash: 用户控制 PBE 的 Salt 问题将在以下情况下出现：

1.数据通过一个不可信赖的数据源进入程序。

2.用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数 (PBKDF) 中的 salt 使用。


如同许多软件安全漏洞一样，Weak Cryptographic Hash: 用户控制 PBE 的 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PBKDF 中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1.攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2.如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

示例 1：以下代码使用用户控制 salt：

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

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

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改环境变量 SALT 来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash:用户控制 PBE 的 Salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序。

2. 用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数中的 salt 使用。


如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制 PBE 的 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PSKDF 中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1. 攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

例 1： 以下代码使用用户控制 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)
...

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改环境变量 SALT 来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash:用户控制 PBE 的 Salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数中的 salt 使用。


如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制 PBE 的 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PSKDF 中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1. 攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

例 1： 以下代码使用用户控制 salt：

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

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 salt 中的文本来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

弱加密散列值：用户控制 PBE Salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据包括在 salt 中，或完全作为基于密码的密钥派生函数中的 salt 使用。


如同许多软件安全漏洞一样，弱加密散列值：用户控制 PBE Salt 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作 PBKDF 中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1. 攻击者可以利用这一漏洞，指定一个空 salt 作为自己的密码。由此，可以轻易地使用许多不同的散列快速地对其密码执行派生，以泄露有关您的应用程序中使用的 PBKDF 实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定派生值。

示例 1：以下代码会使用用户控制的 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)
...

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 UITextField inputTextField 中的文本来操纵用于派生密钥或密码的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash:用户控制 salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据包括在 salt 中，或完全用作加密散列函数中的 salt。

如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作加密散列中的全部或部分 salt。

用户控制 salt 的问题在于，它可以实现几个不同的攻击：

1. 攻击者可以利用这一漏洞，为被散列的数据指定一个空 salt。由此，可以轻易地使用许多不同的散列算法控制被散列的数据，以泄露有关您的应用程序中使用的散列实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定哈希值。

例 1： 以下代码使用用户控制 salt 进行密码散列：

    ...
    salt = getenv("SALT");
    password = crypt(getpass("Password:"), salt);
    ...

Example 1 将成功运行，但任何有权使用此功能的人将能够通过修改环境变量 SALT 来操纵用于对密码执行散列的 salt。此外，此代码还使用了 crypt() 函数，该函数不应用于对密码执行加密散列。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash: 用户控制 salt 问题将在以下情况下出现：

1.数据通过一个不可信赖的数据源进入程序。

2.用户控制的数据包括在 salt 中，或完全用作加密散列函数中的 salt。


如同许多软件安全漏洞一样，Weak Cryptographic Hash: 用户控制 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作加密散列函数中的全部或部分 salt。

用户定义的 salt 可以实现各种不同的攻击：

1.攻击者可以利用这一漏洞，指定一个空 salt 作为散列数据。然后攻击者可以使用许多不同的散列算法快速控制数据，以泄露有关您的应用程序中使用的散列实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他数据值。
2.如果攻击者可以操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这使他们能够计算应用程序的“彩虹表”，并轻松地确定散列值。

示例 1：以下代码使用用户控制 salt 进行密码散列：

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  salt := r.FormValue("salt")
  password := r.FormValue("password")
  ...
  sha256.Sum256([]byte(salt + password))
}

Example 1 中的代码将成功运行，但任何有权使用此功能的人可以通过修改 salt 环境变量来操纵用于对密码执行散列的 salt。此外，此代码还会使用 Sum256 加密散列函数，而该函数不应该用于对密码执行加密散列。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash:用户控制 salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序。

2. 用户控制的数据包括在 salt 中，或完全用作加密散列函数中的 salt。


如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，然后这些数据被用作加密散列函数中的全部或部分 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1. 攻击者可以利用这一漏洞，为被散列的数据指定一个空 salt。由此，可以轻易地使用许多不同的散列算法控制被散列的数据，以泄露有关您的应用程序中使用的散列实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定哈希值。

例 1： 以下代码使用用户控制 salt 进行密码散列：

import hashlib, binascii

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

  hash = hashlib.md5("%s:%s" % (salt, password,)).hexdigest()
  store(username, hash)
...

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 SALT 环境变量来操纵用于对密码执行散列的 salt。此外，此代码还会使用 md5() 加密散列函数，而该函数不应该用于对密码执行加密散列。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash:用户控制 salt 问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据包括在 salt 中，或完全用作加密散列函数中的 salt。

如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制 Salt 是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传递到应用程序，该数据随后用作加密散列中的 salt。

使用用户定义的 salt 的问题在于，它可以实现各种不同的攻击：

1. 攻击者可以利用这一漏洞，为被散列的数据指定一个空 salt。由此，可以轻易地使用许多不同的散列算法控制被散列的数据，以泄露有关您的应用程序中使用的散列实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他密码。
2. 如果攻击者能够操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这将使他们能够计算应用程序的“彩虹表”，并更轻松地确定哈希值。

例 1： 以下代码使用用户控制 salt 进行密码散列：

    ...
    salt = req.params['salt']
    hash = @userPassword.crypt(salt)
    ...

Example 1 中的代码将成功运行，但任何有权使用此功能的人将能够通过修改 salt 参数来操纵用于对密码执行散列的 salt。此外，此代码还使用了 String#crypt() 函数，该函数不应用于对密码执行加密散列。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

在以下情况下会发生 Weak Cryptographic Hash: 用户控制 salt 问题将在以下情况下出现：

1.数据通过一个不可信赖的数据源进入程序。

2.用户控制的数据包括在 salt 中，或完全用作加密散列函数中的 salt。


如同许多软件安全漏洞一样，Weak Cryptographic Hash: 用户控制 Salt 是到达终点的一个途径，其本身并不是终点。利用这种漏洞，攻击者可将恶意数据传递到应用程序，然后这些数据被用作加密散列函数中的全部或部分 salt。

用户定义的 salt 可以实现各种不同的攻击：

1.攻击者可以利用这一漏洞，指定一个空 salt 作为散列数据。然后攻击者可以使用许多不同的散列算法快速对受其控制的数据进行散列操作，以泄露有关您的应用程序中使用的散列实现的信息。这样，通过限制所用散列的特定变体，可以更轻松地“破解”其他数据值。
2.如果攻击者可以操纵其他用户的 salt，或者诱骗其他用户使用空 salt，这使他们能够计算应用程序的“彩虹表”，并轻松地确定散列值。

示例 1：以下代码使用用户控制的 salt 来派生加密密钥：

let saltData = userInput.data(using: .utf8)

sharedSecret.hkdfDerivedSymmetricKey(
    using: SHA256.self,
    salt: saltData,
    sharedInfo: info,
    outputByteCount: 1000
)

示例 1 中的代码将成功运行，但任何有权使用此功能的人可以通过修改 userInput 的值来操纵用于派生加密密钥的 salt。一旦程序发布，撤消与用户控制的 salt 相关的问题就会非常困难，因为很难知道恶意用户是否确定了密码散列的 salt。

数字签名是一种用于确定数字消息真实性和完整性的技术。数字签名算法 (DSA) 现已过时，不应再使用。与 RSA 等其他数字签名算法不同，DSA 存在固有缺陷。它需要每条消息的机密值 k，该值必须是加密随机、对外保密且绝不能重复使用的。如果攻击者可以猜出 k 值或者诱骗签名者使用其提供的值，则他们可以恢复私钥，然后伪造任何签名，从而冒充合法签名者。类似地，如果重复使用 k 值对多条消息进行签名，则攻击者可以恢复私钥。

数字签名是一种用于确定数字消息真实性和完整性的技术。数字签名算法 (DSA) 现已过时，不应再使用。与 RSA 等其他数字签名算法不同，DSA 存在固有缺陷。它需要每条消息的机密值 k，该值必须是加密随机、对外保密且绝不能重复使用的。如果攻击者可以猜出 k 值或者诱骗签名者使用其提供的值，则他们可以恢复私钥，然后伪造任何签名，从而冒充合法签名者。类似地，如果重复使用 k 值对多条消息进行签名，则攻击者可以恢复私钥。

数字签名是一种用于确定数字消息真实性和完整性的技术。数字签名算法 (DSA) 现已过时，不应再使用。与 RSA 等其他数字签名算法不同，DSA 存在固有缺陷。它需要每条消息的机密值 k，该值必须是加密随机、对外保密且绝不能重复使用的。如果攻击者可以猜出 k 值或者诱骗签名者使用其提供的值，则他们可以恢复私钥，然后伪造任何签名，从而冒充合法签名者。类似地，如果重复使用 k 值对多条消息进行签名，则攻击者可以恢复私钥。

当前的密码指南建议，RSA 和 DSA 算法使用的密钥长度至少应为 2048 位。但是，计算能力和因子分解技术方面的持续进步 [1] 意味着未来将不可避免地需要提高建议的密钥大小。

示例 1：以下代码生成 1024 位 DSA 签名密钥。

...
DSA dsa = new DSACryptoServiceProvider(1024);
...

当前的密码指南建议，RSA 和 DSA 算法使用的密钥长度至少应为 2048 位。但是，计算能力和因子分解技术方面的持续进步 [1] 意味着未来将不可避免地需要提高建议的密钥大小。

例 1： 以下代码生成 1024 位 DSA 签名密钥。

...
DSA_generate_parameters_ex(dsa, 1024, NULL, 0, NULL, NULL, NULL);
...

当前的密码指南建议，RSA 和 DSA 算法使用的密钥长度至少为 2048 位。但是，计算能力和因子分解技术方面的持续进步 [1] 意味着未来将不可避免地需要提高建议的密钥大小。

示例 1：以下代码可生成 1024 位 DSA 签名密钥。

...
dsa.GenerateParameters(params, rand.Reader, dsa.L1024N160)
privatekey := new(dsa.PrivateKey)
privatekey.PublicKey.Parameters = *params
dsa.GenerateKey(privatekey, rand.Reader)
...

当前的密码指南建议，RSA 和 DSA 算法使用的密钥长度至少应为 2048 位。但是，计算能力和因子分解技术方面的持续进步 [1] 意味着未来将不可避免地需要提高建议的密钥大小。

例 1： 以下代码生成 1024 位 DSA 签名密钥。

...
from Crypto.PublicKey import DSA
key = DSA.generate(1024)
...

当前的密码指南建议，RSA 和 DSA 算法使用的密钥长度至少应为 2048 位。但是，计算能力和因子分解技术方面的持续进步 [1] 意味着未来将不可避免地需要提高建议的密钥大小。

例 1： 以下代码生成 1024 位 DSA 签名密钥。

require 'openssl'
...
key = OpenSSL::PKey::DSA.new(1024)
...

加密签名的生成涉及多个步骤，错过对任何必需步骤的调用都会削弱所生成签名的强度。

例 1： 以下代码跳过了对方法 EVP_SignUpdate 的调用，这将会导致创建不基于任何数据的签名：

...
rv = EVP_SignInit(ctx, EVP_sha512());
...
rv = EVP_SignFinal(ctx, sig, &sig_len,  key);
...

通过允许用户控制的值来确定密钥大小，攻击者可以指定一个空密钥，从而可以修改确保加密数据完整性的加密签名。即使要求使用非零值，攻击者也仍然可以指定尽可能低的密钥大小值，降低加密数据的完整性。

弱加密签名：用户控制密钥大小问题将在以下情况下出现：

1.数据通过一个不可信赖的数据源进入程序。

2.用户控制的数据被用作加密签名函数中密钥大小参数的全部或一部分。

如同许多软件安全漏洞一样，Weak Cryptographic Signature: 用户控制密钥大小是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者将恶意数据传送到应用程序，这些数据随后被用作用于执行加密的密钥大小值的全部或一部分。

当前的密码指南建议，RSA 和 DSA 算法使用的密钥长度至少为 2048 位。但是，计算能力和因子分解技术方面的持续进步 [1] 意味着未来将不可避免地需要提高建议的密钥大小。即使将用户输入用作部分密钥大小，也会削弱签名的安全性，进而削弱加密数据的完整性。

示例 1：下面的代码通过用户控制的密钥大小参数生成 DSA 签名密钥：

...
dsa.GenerateParameters(params, rand.Reader, key_len)
privatekey := new(dsa.PrivateKey)
privatekey.PublicKey.Parameters = *params
dsa.GenerateKey(privatekey, rand.Reader)
...

用户几乎不需要指定 key_len 的能力。在此类情况下，您应该验证它不仅是一个数值而且还处于密钥大小值的合理范围内。对于大多数用例，请选择一个足够大的硬编码密钥大小。

允许用户控制的值来确定密钥大小会让攻击者可以指定一个空密钥，导致攻击者可以修改确保加密数据完整性的加密签名。即使要求使用非零值，攻击者也仍然可以指定尽可能低的密钥大小值，降低加密数据的完整性。

在以下情况下会发生 Weak Cryptographic Hash:用户控制密钥大小问题将在以下情况下出现：

1. 数据通过一个不可信赖的数据源进入程序

2. 用户控制的数据被用作加密签名函数中密钥大小参数的全部或一部分

如同许多软件安全漏洞一样，Weak Cryptographic Hash:用户控制密钥大小是到达终点的一个途径，其本身并不是终点。从本质上看，这些漏洞是显而易见的：攻击者将恶意数据传送到应用程序，这些数据随后被用作执行加密的密钥大小值的全部或一部分。

当前的密码指南建议，RSA 和 DSA 算法使用的密钥长度至少应为 2048 位。但是，计算能力和因子分解技术方面的持续进步 [1] 意味着未来将不可避免地需要提高建议的密钥大小。即使将用户输入用作部分密钥大小，也可能会大大削弱签名的安全性，进而削弱加密数据的完整性。

例 1：下面的代码使用用户控制的密钥大小参数生成 DSA 签名密钥：

require 'openssl'
...
key_len = io.read.to_i
key = OpenSSL::PKey::DSA.new(key_len)
...

用户应该能够确定 key_len 的用例没有几个，即使在这些用例中，也应该有适当的保护来验证它不仅是一个数值而且还在密钥大小值的合理范围内。对于大多数用例，这应该是一个足够高的硬编码数字。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥要克服巨大的计算障碍，但今天，攻击者借助常用设备就能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法，特别是使用不够长密钥的加密算法，不再能对含有敏感数据的使用提供充足的保护，随着技术的进步，在合理的时间内通过“强行破解”获得长度很短的加密密钥已经在计算上变为可行。例如，在二十世纪七十年代首次开发出该算法时，在 DES 中使用的 64 位密钥造成了巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

例 1：下列代码执行了算法不安全的加密 (DES)：

...
CCCrypt(kCCEncrypt,
        kCCAlgorithmDES,
        kCCOptionPKCS7Padding,
        key,
        kCCKeySizeDES, // 64-bit key size
        iv,
        plaintext,
        sizeof(plaintext),
        ciphertext,
        sizeof(ciphertext),
        &numBytesEncrypted);
...

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法，特别是使用不够长密钥的加密算法，不再能对含有敏感数据的使用提供充足的保护，因为技术的进步使得在合理的时间内通过“强行破解”获得长度很短的加密密钥在计算上是可行的。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 64 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

示例 1：以下代码执行了算法不安全的加密 (DES)：

...
let iv = getTrueRandomIV()
...
let cStatus = CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmDES),
UInt32(kCCOptionPKCS7Padding),
key,
keyLength,
iv, 
plaintext, 
plaintextLength,
ciphertext, 
ciphertextLength,
&numBytesEncrypted)
...

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。

过时的加密算法（如 DES）无法再为敏感数据的使用提供足够的保护。加密算法依赖于密钥大小，这是确保加密强度的主要方法之一。加密强度通常以生成有效密钥所需的时间和计算能力来衡量。计算能力的提高使得在合理的时间内获得较小的加密密钥成为可能。例如，在二十世纪七十年代首次开发出 DES 算法时，要破解在该算法中使用的 56 位密钥将面临巨大的计算障碍，但今天，使用常用设备能在不到一天的时间内破解 DES。