终极哈希保护 - 概念的讨论

Xeo*_*oss -2 security hash rainbowtable

好的,因此哈希的整个问题是用户不会输入长度超过15个字符的密码.大多数人只使用4-8个字符,使攻击者很容易用彩虹表破解.

解决方案,使用用户salt使哈希输入更复杂,超过50个,这样他们就永远无法生成一个表(对于那些大小的字符串来说是大的).另外,他们必须为每个用户创建一个新表.问题:如果他们下载数据库,他们将获得用户盐,所以如果他们足够关心你就回到原点.

解决方案,使用网站"胡椒"加上用户盐,然后即使他们得到数据库,他们仍然必须知道配置文件.问题:如果他们可以进入您的数据库,他们可能也会进入您的文件系统并发现您的网站.

因此,所有这些都已知 - 让我们假设攻击者进入您的网站并获取所有内容,一切都是如此.那你现在做什么?

在讨论的这一点上,大多数人回答"谁在乎这一点?".但这只是一种廉价的说法,"我不知道下一步该做什么,所以它不可能那么重要".可悲的是,在其他任何地方我都问过这个回答的问题.这表明大多数程序员都错过了一个非常重要的观点.

让图像显示您的网站就像其他95%的网站一样,用户数据 - 甚至是完全的服务器访问 - 都不值得蹲下.攻击者碰巧是在你的一个用户"Bob"之后,因为他知道"Bob"在你的网站上使用与在银行网站上使用相同的密码.他也碰巧知道鲍勃在那里有他的人生储蓄.现在,如果攻击者可以破解我们的网站哈希,剩下的将是小菜一碟.

所以这是我的问题 - 如何在没有任何可追踪路径的情况下扩展密码的长度?或者,如何使哈希过程复杂化并及时复制?我唯一想到的就是你可以重新散列数千次哈希,并将创建最终彩虹表所花费的时间增加1000倍.这是因为攻击者在创建表时必须遵循相同的路径.

还有其他想法吗?

eri*_*son 6

解决方案,使用用户salt使哈希输入更复杂,超过50个,这样他们就永远无法生成一个表(对于那些大小的字符串来说是大的).另外,他们必须为每个用户创建一个新表.问题:如果他们下载数据库,他们将获得用户盐,所以如果他们足够关心你就回到原点.

这种推理是错误的.

彩虹表(这是一般字典攻击的具体实现)在时间上交换空间.但是,生成字典(彩虹或其他)需要花费很多时间.只有当它可以用于多个哈希时才值得.盐防止这种情况.盐不需要保密,只需要给定密码不可预测.这使得攻击者拥有为该特定盐生成的字典的机会可忽略不计.

  • 不,创建彩虹表很慢.即使在分布式架构中工作的许多贡献者的共同努力下,创建一个8字符的混合字母数字表也是一项艰巨的任务.如果使用一轮散列,只需要一周时间.如果使用几千次好散列迭代,则无法在一周内为简单的7字符混合字母数字密码创建表.我知道我告诉你的并不令人信服,所以我恳请你自己尝试一下. (2认同)