1

首先，我认为需要指出的是：我正在为通常互联网速度较慢的手机制作应用程序，因此需要在速度和安全性之间进行折衷。

我将使用相同的函数（当然，用于创建哈希的变量不同）来创建用户的自动登录 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 攻击的容易目标？

4

2 回答 2

2

你不是密码学专家。不要尝试创建自己的加密结构，因为它们可能会以某种微妙的方式存在缺陷，而您对加密的了解不足而无法识别。

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

无论如何，客户端设备的速度/功率与您可以并且应该在服务器端使用的数据加密的安全性完全没有关系。如果您担心 PBKDF2 会给服务器带来过多负载，请对登录尝试应用某种形式的速率限制。

于 2012-06-18T17:35:54.760 回答
0

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

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

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

编辑：关于盐的注释来自 OWASP，但它似乎已被删除。原文是：

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

于 2012-06-18T17:33:40.000 回答