2

我一直在尝试使用 pbkdf2 使我的用户密码真正安全。

密码哈希可以很好地进入数据库，但盐不是。

似乎盐包含 mysql 列不喜欢的外来字符。

我的“用户”表中的所有列都是 UTF8_unicode_ci。

这是我的密码哈希：

$size = mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB);
$salt = mcrypt_create_iv($size, MCRYPT_DEV_RANDOM);

$passHash = pbkdf2('SHA512', $pass, $salt, 8192, 256) ;

include("dbconnect.php") ;

$result = $dbh->prepare("INSERT INTO users (name, email, qq, password, salt)VALUES(?, ?, ?, ?, ?)") ;
    $result->bindParam(1, $name, PDO::PARAM_STR) ;
    $result->bindParam(2, $email, PDO::PARAM_STR) ;
    $result->bindParam(3, $qq, PDO::PARAM_STR) ;
    $result->bindParam(4, $passHash, PDO::PARAM_STR) ;
    $result->bindParam(5, $salt, PDO::PARAM_STR) ;
$result->execute() ;

和 pbkdf2：

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
* $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
* $key_length - The length of the derived key in bytes.
* $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
* Returns: A $key_length-byte key derived from the password and salt.
*
* Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
*
* This implementation of PBKDF2 was originally created by https://defuse.ca
* With improvements by http://www.variations-of-shadow.com
*/
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false){
$algorithm = strtolower($algorithm);
if(!in_array($algorithm, hash_algos(), true))
    die('PBKDF2 ERROR: Invalid hash algorithm.');
if($count <= 0 || $key_length <= 0)
    die('PBKDF2 ERROR: Invalid parameters.');

$hash_length = strlen(hash($algorithm, "", true));
$block_count = ceil($key_length / $hash_length);

$output = "";
for($i = 1; $i <= $block_count; $i++) {
    // $i encoded as 4 bytes, big endian.
    $last = $salt . pack("N", $i);
    // first iteration
    $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
    // perform the other $count - 1 iterations
    for ($j = 1; $j < $count; $j++) {
        $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
    }
    $output .= $xorsum;
}

if($raw_output)
    return substr($output, 0, $key_length);
else
    return bin2hex(substr($output, 0, $key_length));
}

另外，我刚刚注意到它为相同的密码存储了完全不同的哈希值。

我这样做对吗？

4

2 回答 2

1

很难对“我这样做对吗？”这样宽泛的问题给出准确的答案。我可以说，在散列之前对密码进行加盐处理的全部目的是使生成的散列在用户之间是唯一的。因此，为相同的输入获得不同的输出是一件好事。查找“字典攻击”以获取有关原因的更多信息。

至于您的代码，听起来您真正想知道的是为什么您的盐没有存储到数据库中。我能想到的调试步骤，没有更具体的细节

  • $salt 可能是假的， mcrypt_create_iv 出错时返回假（不太可能是因为您上面提到的哈希输出差异，但值得检查。
  • 正如您所怀疑的那样，无法识别输出字符。在添加到您的准备之前，您可以尝试将数据库列类型转换为 varbinary 并使用字符串转换为二进制或十六进制解码器。
  • 尝试使用不同字符编码的列类型，看看你的盐可以进入哪种列类型。UTF-8 对每个字符使用可变数量的字节，这让我在处理绝对的事情时感到不舒服。盐和散列通常被认为是固定的位字段，为方便起见，通常以十六进制格式表示。

如果您提供服务器环境、php 版本、mysql 版本等以及一些未正确存储的盐样本，我也许可以缩小问题的范围。

于 2012-07-21T02:44:14.263 回答
1

在存储到 varchar 列之前，您应该将结果转换为base64 编码。Base64 编码基本上将字节数组转换为 ASCII 范围内的可显示（因此是 SQL 可存储）字符。

于 2015-03-11T14:23:38.733 回答