客户端散列以减少密码猜测启发式算法的值
是的，这是“又一个客户端的问题”。但是，别走了，我觉得这里有一些价值。
当密码哈希数据库被盗时，我想做一些事情来减轻对整个社区的影响。(见: LinkedIn、Match.com、Yahoo等)
在这种情况下，通过对泄露密码的统计分析，改进了用户密码定向破解的启发式算法。我想帮助阻止这一切的发生。
这里的想法是:以用户的明文密码，缓慢散列它的客户端，尽可能多的轮可以进行口述。然后，使用哈希作为传递给服务器的密码。将密码-客户端散列处理为普通密码，并在服务器端再次进行慢速散列。
这将使我的密码数据库对启发式攻击免疫。(嗯，实际上并不是免疫的，只是使用启发式方法非常昂贵。)
不过，我担心的是，客户端散列输出中的熵降低可能会消除我在消除启发式的价值方面所获得的收益。
如何量化这一权衡？对这个方法有什么想法吗？
编辑
我要说的是，我试图降低启发式攻击的价值。也就是说，我想让'Password1‘和'tqwe657fdh’一样好的密码。也就是说，攻击者必须搜索相同的空间才能破解任何一个空间。
另一个编辑
讨论帮助我澄清了我的想法：
由于最近泄露了这么多大型密码数据库，以及由此产生的对常见密码和模式的分析，我认为密码破解系统中使用的启发式方法必须得到改进。
GPU辅助哈希执行(http://openwall.info/wiki/john/GPU)方面的最新进展进一步将CPU不平衡的好处转移到攻击者身上。(无论如何，它已经相当不平衡了。一旦系统接近互联网规模，在集中式服务器硬件上处理缓慢哈希密码是一项艰巨的任务。)
我想做两件事：
消除攻击者从试探中得到的好处，从而强制进行真正的蛮力攻击.
减少利益，我的密码数据库将对黑客社区，一旦它被偷了我。
我怀疑我的想法可能有帮助，但我需要一种量化权衡的方法。
回答 2
Security用户
发布于 2013-03-04 16:03:20
对于结果数据库，散列是发生在客户端还是服务器端并不重要。攻击者看到哈希，并尝试密码。
客户端散列有以下主要后果：
- CPU用于客户端，而不是服务器；因为服务器一次可能必须管理100个客户端，而客户机一次只能登录一台服务器，这似乎是对可用CPU的有效使用。
- 但是，在Web上下文中，客户机上的CPU意味着Javascript。这更像是CPU的1%，因为Javascript的开销(即使使用JIT编译，Javascript确实不擅长CPU密集型的任务)。
- 由于散列需要了解salt，所以您必须更改协议:客户端发送用户名，服务器使用salt进行响应，只有这样，客户端才会进行散列。这可能很容易，也可能不容易应用于给定的协议；它需要额外的往返。
因此，这样就不会有很大的安全增长。如果您可以在客户端上存储，情况就会发生变化。这样，您就可以在客户端上存储一个密钥(某种秘密)，并使用在用户密码(键入的)上计算的MAC作为发送给服务器的“密码”。由于入侵服务器的攻击者获得了数据库，而不是存储在客户端上的任何东西，这就带来了您想要的“社区服务”。另一方面，客户端上的密钥存储会带来自己的一系列问题(特别是，用户不能再轻松地切换机器；密钥必须以某种方式从一台机器传输到另一台机器)。可以使用专用存储服务器来帮助解决这些存储问题。在很大程度上，这个解决方案是KeePass模型。
Security用户
发布于 2013-03-04 18:36:32
在服务器或客户机上没有特定的增益，实际上，听起来您只是在使用中间结果作为客户端和服务器端散列之间的切换点。您可以节省性能，以使哈希的成本不高，但最终，由于客户端将中间哈希作为有效输入返回，攻击者仍然只需对抗服务器版本。
假设我在"mypassword“上本地运行1000个散列迭代，以获得"jdqfr3bt”的值。然后，客户机必须将它提供给服务器，服务器执行它可以执行的10次迭代，以获得与DB匹配的"91jf35j“，因此它允许它进入。
现在，作为一个攻击者，我从DB中得到了91jf35j，并查找到"jdqfr3bt“值与其匹配。然后，我简单地提供它作为我的客户端散列的“结果”，而不去实际做任何事情。服务器认为它是有效的。它确实使从字典开始变得更昂贵，但是一个纯粹的彩虹表不会受到影响。
https://security.stackexchange.com/questions/31920
复制相似问题
腾讯云开发者
