是否有像bcrypt这样的慢速Javascript哈希算法?

时间:2012-11-07 17:42:43

标签: javascript hash sha bcrypt

我不是在讨论服务器端node.js。

我想对我网站客户端的密钥使用慢哈希算法。我找到了SHA-256 seem to be reliable的实现。我还发现this question导致OP creating his own library

但是,我不确定是否应该进行多轮SHA散列或信任某些代码,因为我不是安全专家,并且它似乎没有大量跟随者只是“盯着”由36人。

在这种情况下,最佳选择是什么?一旦我选择了某些东西,我(基本上)就无法改变方法。

我想要一个缓慢的散列(非加密)算法,我宁愿它产生一个短字符串。例如,慢速60 char bcrypt vs fast 70 char SHA-256。

2 个答案:

答案 0 :(得分:7)

目前有三种密钥派生函数被广泛认为可以抵御暴力破解尝试。密钥派生函数与常规哈希算法略有不同,因为即使面对基于GPU的现代计算,它们设计也很慢。

我将按照理论安全性的顺序列出它们:

  • PBKDF2由RSA设计,基于SHA,是NIST推荐的算法。您可以在浏览器中使用a couple implementations

    节点用户注意:节点的crypto模块有built-in PBKDF2 function。使用它。

  • 基于Blowfish的
  • bcrypt比PBKDF2稍微安全一些。它已经过相对良好的测试和验证,但是如果这是您的考虑因素,则没有任何标准机构的批准。有a generic JS implementation here

    节点用户注意事项:使用node.bcrypt,它在单独的线程上执行计算成本高昂的东西。

  • 最后,scrypt是理论上最安全(最慢)的KDF。遗憾的是,该算法非常新,因此尚未通过加密社区的严格研究和测试进行验证。但是,on track to become a IETF standard

    因为算法是如此新,所以很难找到实现。我只能找到this half-baked one。虽然安全性方面非常有前途,但在算法本身及其实现都经过验证安全之前,我不建议使用scrypt。

这三个实际比较如何? scrypt paper进行了比较:

algorithm comparison table

实际上,即使是PBKDF2,除了政府之外的所有人都要破解一个8个字符的密码,因此成本过高。

答案 1 :(得分:0)

您始终可以忽略快速SHA-256的最后10个字符。或者x或要包含的前10个字符。

SHA具有可变数量的轮次。两轮SHA应该是可逆的。我有一个模糊的想法,即20轮被认为是“安全的”。 30轮应该是“高度安全的”,并且50轮在所有安全性方面实际上都没有改进。

SHA的设计是安全的 - 不是希望破解者拥有足够慢的机器 - 而是通过数学证明。如果并且当每轮中不可逆位的数量增加并且置换为256位散列码时,将永远不会有足够的计算机能力来尝试生成该特定散列码的所有可能序列。在宇宙中甚至没有足够的能量来包裹256位计数器。

除非产生哈希的字符串非常小或者在某人的监视器上写在帖子上。