我已经知道在将用户密码发送到服务器之前，我将在 sha512 或 n*x 中对用户密码进行 n 次哈希处理，然后再将其发送到服务器。一旦到达服务器，我将使用 bcrypt set 来使用 ~1/100th一秒钟。在继续之前，关于我使用 sha512 而不是 sha1 背后的推理，我想说明几件事。首先，我知道客户端安全是一个笑话。其次，我知道一个 Man- in-the-middle 攻击可以剥离页面的 javascript 的哈希函数。最后，我意识到这将意味着人们将无法在没有启用 javascript 的情况下登录。
我目前正在使用 sha512 设置为在 ie8 [2] 中使用 ~1s，它是这样设置的。
- 获取用户的密码和用户名。
- 添加一个静态随机数（以真正延长它，仅此而已）。
- 通过散列函数对其进行散列，在本例中为 sha512。
- 取那个散列，通过 sha512 散列它，将当前循环号打包成一个字节。
- 重复步骤 4 n 次。
- 完成后，获取该值并将其放入密码字段中。
- 最后让系统POST到服务器。
那么，做 n*x 的 sha1 哈希与 n 次 sha512 的优势是什么？使用该系统的全部要点是，如果发生数据库泄漏，攻击者将不得不将尝试查找密码所花费的时间增加 z 时间。此外，通过在它到达服务器之前对其进行散列（以及使用 TLS），它可以实现，因此，如果出现一些奇怪的错误，密码永远不会被视为纯文本。
我相信 sha512 是更好的选择，因为 sha1 已经损坏，因此它的安全性不值得，但另一方面。我为 sha512[1][] 找到的最快的 javascript 库比本机代码慢约 50 倍，但我发现的最快的 sha1 库仅比本机代码慢约 17 倍。
因此，问题是与 sha512 的较少迭代相比，损坏的 sha1 是否会导致整体安全性的更大损失，从而降低攻击者的速度，到目前为止，sha2 系列中没有一个被远程破坏。以前有没有其他人处理过这个问题？
[1]：通过 fuzzing 产生与 c 实现/php 相同的哈希值，对于约 300 个输入产生相同的哈希值。
[2]：在 ie10 发布一年后，我想放弃对 ie8 的支持，这样我就可以将哈希数提高到更合理的水平。