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

时间:2009-02-17 23:38:18

标签: security silverlight-2.0 hash

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

这样做有什么安全问题?

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

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

4 个答案:

答案 0 :(得分:2)

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

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

  

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

     

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

     

答案 1 :(得分:2)

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

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

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

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

答案 2 :(得分:1)

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

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

答案 3 :(得分:0)

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