代码之家  ›  专栏  ›  技术社区  ›  AndiDog

密码盐:前置与附加

  •  10
  • AndiDog  · 技术社区  · 14 年前

    我刚刚看了Django中密码散列的实现,发现 that it prepends the salt ,所以散列的创建方式如下 sha1(salt + password) ,例如。

    在我看来,盐有两个用途

    1. 防止彩虹表查找

      好吧,准备/添加盐对彩虹表并没有什么影响。

    2. 对暴力/字典攻击的强化

      这就是我的问题所在。 如果有人想从被盗密码数据库中攻击单个密码,他需要尝试很多密码(例如字典单词或[a-Za-z0-9]排列)。

      假设我的密码是“abcdef”,salt是“salt”,攻击者会尝试所有[a-z]{6}密码。

      用预先准备好的盐,你必须计算 hash("salt") ,存储哈希算法的状态,然后从该点开始对每个置换进行操作。也就是说,遍历所有的置换将需要26^6 copy hash算法的状态结构操作和26^6 hash(permutation of [a-z]{6}) 操作。由于复制哈希算法的状态是快速的,所以盐在这里几乎不增加任何复杂性,不管它有多长。

      但是,附加一个盐,攻击者必须计算 hash(permutation of [a-z]{6} + salt) 对于每个置换,导致26^10个哈希操作。很明显, 附加 盐的复杂性取决于盐的长度。

    我不认为这是因为历史原因,因为Django是一个相当新的。那么这是什么意思 准备 盐?

    3 回复  |  直到 14 年前
        1
  •  10
  •   CodesInChaos    14 年前

    两者都不要,用标准 Key derivation function 喜欢 PBKDF2 . 千万别把你自己的密码翻出来。很容易出错。PBKDF2使用许多迭代来防止bruteforce,这比简单的排序有更大的改进。

    在处理salt之后预先计算hash函数的内部状态的技巧可能不太容易实现,除非salt的长度与底层块cypher的块长度相对应。

        2
  •  1
  •   blaze    14 年前

    如果salt是预先准备好的,攻击者可以为salt创建哈希状态数据库(假设salt足够长,可以执行哈希步骤),然后运行字典攻击。

    但是,如果附加了salt,攻击者就可以为密码字典创建这样的数据库,并且只计算salt的散列。由于salt通常比password短(比如4个字符的salt和8个字符的password),所以攻击速度会更快。

        3
  •  0
  •   cababunga    14 年前

    当然,您的观点是正确的;但是,实际上,如果您想增加计算散列所需的时间,只需使用更长的散列即可。例如,SHA256而不是SHA1。