Question

首先，我认为需要指出的是：我正在为移动电话申请通常具有足够慢的互联网，因此需要在速度和安全性之间做出妥协。

我将使用相同的功能（当然，用于创建哈希的不同变量）来创建用户的自动登录cookie并存储他们的密码。

到目前为止看起来像这样：

function multiSHA($toSha, $mode=0, $count=100) { //$mode=1 to create cookies with uniqid, or =0 for hashing with externally specified salt (added to $toSha) and static pepper
    $toSha=hash('sha512',$toSha); //so that I know the length of the string below
    if ($mode==0) {
        for ($i=0; $i<$count; ++$i) {
            $p1=hash('sha512',substr($toSha,0,64)); // since I know the length
            $p2=hash('sha512',substr($toSha,64,128));
            $pepper=hash('sha512','This is my static pepper.');
            $toSha=hash('sha512',$p1.$pepper.$p2);
        }
    }
    else {
        for ($i=0; $i<$count; ++$i) {
            $p1=hash('sha512',substr($toSha,0,64));
            $p2=hash('sha512',substr($toSha,64,128));
            $uniqid=hash('sha512',uniqid('This is my static pepper.',true));
            $toSha=hash('sha512',$p1.$uniqid.$p2);
        }
    }
    return $toSha;
}

现在，这足以存储密码和cookie数据吗？我不能使用PBKDF2，因为它占用了很多太多的资源，但是这个资源相当轻量级。攻击者不知道for循环重复多少次，我还会将cookie存储在一个单独的表中以进行一些额外的安全检查（例如用户代理）。

此外，我应该准备多少个循环才能使其足够安全而不会使我的网站成为DDOS攻击的轻松目标？

Answer 1

您不是加密专家。不要试图创建自己的加密结构，因为它们可能会以某种微妙的方式存在缺陷，以至于您对crypto的识别知之甚少。

至少，您的“multiSHA”哈希方案在模式0中缺少盐析，并且在模式1中不可重复（因此完全无用）。

在任何情况下，客户端设备的速度/功率绝对不会影响您可以在服务器端使用的数据加密的安全性。如果您担心PBKDF2会对服务器施加过多负载，请对登录尝试应用某种形式的速率限制。

Answer 2

查看OWASP - Password Storage Cheat Sheet的指南。

目前，他们建议对密码进行64,000次哈希迭代。我找不到参考文献（我认为它是在OWASP上），但我记得最近看到，截至2012年，盐应该至少为24字节。

我认为目前，使用盐的64,000次SHA-512迭代应足以保证您的安全。

编辑：有关盐的说明来自OWASP，但它似乎已被删除。原文是：

因为我们已经看到了所有密码的野外彩虹表大小为24个字符，建议使用至少24字节的盐最小长度。

密码哈希：这对wap应用程序来说足够了吗？

2 个答案: