传递哈希密码时有哪些安全问题？

Question

我在网页上有一个Silverlight控件，并希望将用户名和散列密码作为InitParams的一部分传递给此控件。

这样做有什么安全问题？

用户必须登录才能访问此页面。但是，我猜测浏览器可能会使用Silverlight控件缓存页面，这会缓存用户名和哈希密码。

这让我想到了一个更具体的问题：是否有一个HTML元标记告诉浏览器不要缓存页面？

Answer 1

安全性：首先考虑恶意用户可能对散列密码的潜在用途（包括与其他存储的哈希进行比较）。

缓存：是的，有一个元标记，但除非必须，否则不应使用它;最好设置HTTP标头

  

HTML作者可以将标签放在描述其属性的文档部分中。这些元标记通常用于相信它们可以将文档标记为不可缓存，或者在特定时间到期。

     

Meta标签易于使用，但效果不是很好。这是因为它们只受到一些浏览器缓存（实际上是读取HTML）的尊重，而不是代理缓存（几乎从不读取文档中的HTML）。虽然将一个Pragma：no-cache元标记放入网页可能很诱人，但它并不一定会使它保持新鲜。

     

  来自Caching Tutorial for Web Authors and Webmasters (HTML Meta Tags and HTTP Headers) 的
•   

Answer 2

如果攻击者可以获得哈希密码，则可以使用 rainbow table 来反转它。彩虹表基本上是一个庞大的数据库，包含所有可能的密码，达到一定的大小，并由其散列索引。我认为这是最终的速度 - 空间权衡。对于最多7个字符的密码，仅包含小写字母和数字，彩虹表可以容纳几千兆字节。对于较长的密码（或具有较少字符限制的密码），所需的大小会呈指数级增长。

要打败这种攻击，你需要为哈希加盐。 Salting意味着您在对密码进行散列之前将随机盐值添加到密码中。这个盐可以在哈希旁边以未加密的方式存储。由于每个密码都使用另一个随机盐进行哈希处理，因此彩虹查找表变得无用。彩虹表不能考虑所有可能的盐值，因为所需的数据库大小随着盐的大小呈指数增长。

即便如此，仍然可以通过暴力找到与salt + hash匹配的弱密码。这可以通过在密码上使用一些质量控制启发式来修复（最小长度，混合某些字符类型，如小写/大写/数字/其他，而不仅仅是最后的1 ......）。

总而言之，我会说暴露散列的安全风险足够大，你最好避免它。

Answer 3

我的问题是，控件可以用散列密码做什么？它似乎不能用于任何有用的目的，为什么它传递给控件？

对密码进行哈希处理，以使恢复原始密码在计算上不可行。因此，假设哈希是正确完成的，那么暴露它就没有风险了。但是，控件认为它需要哈希密码这一事实让我很怀疑。

Answer 4

请记住，MD5哈希已被强力攻击破解，因此在打开时使用哈希密码并非100％安全，但对于大多数情况，它可能不是问题，尤其是如果您使用更强大的哈希算法。