密码散列：这对于 wap 应用程序来说足够了吗？

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，因为它占用了 too 太多资源，但这个相当轻量级。攻击者不知道for 循环重复了多少次，我还将cookie 存储在单独的表中以进行一些额外的安全检查（例如用户代理）。

另外，我应该准备多少次循环才能保证足够安全不会让我的网站成为 DDOS 攻击的容易目标？

Answer 1

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

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

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

Answer 2

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

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

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

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

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