传递散列密码时有什么安全问题？

Question

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

这样做的安全性问题是什么？

用户必须登录才能访问此页面。不过，我猜测浏览器可能会用Silverlight控件缓存页面，这会缓存用户名和散列密码。

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

Answer 1

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

对密码进行散列以使其恢复原始密码在计算上不可行。所以，假设散列正确完成，暴露它没有风险。但是，控制器认为它需要散列密码的事实让我感到怀疑。

Answer 2

请记住，MD5哈希已被破解强力攻击，所以在开放时使用哈希密码不是100％安全的，但对于大多数情况下，它可能是一个非问题，特别是如果您使用更强大的哈希算法。

Answer 3

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

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

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

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

• 从Caching Tutorial for Web Authors and Webmasters (HTML Meta Tags and HTTP Headers)

Answer 4

如果攻击者能够在哈希密码获取，他有可能通过使用rainbow table扭转它。一张彩虹表基本上是一个庞大的数据库，其中包含所有可能的密码，达到一定的大小，并由它们的散列索引。我认为它是最终的速度空间折衷。对于最多7个字符的密码，只包含小写字母和数字，彩虹表可以放入几千兆字节。对于更长的密码（或字符限制较少的密码），所需的大小确实呈指数级增长。

为了击败这个攻击，你需要盐哈希。盐化意味着您在密码之前添加一个随机盐值到密码。该盐可以在哈希旁边以未加密方式存储。由于每个密码都与另一个随机盐混合在一起，所以彩虹查找表变得毫无用处。彩虹表不能考虑所有可能的盐值，因为所需的数据库大小随着盐的大小呈指数增长。

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

总而言之，我认为揭示散列的安全风险已经足够大，以至于你更好地避免它。