散列和加盐密码对字典攻击是否安全？答案

【问题标题】：Are hashed and salted passwords secure against dictionary attacks?散列和加盐密码对字典攻击是否安全？
【发布时间】：2010-11-09 20:03:47
【问题描述】：

我了解 salts 会将相同的密码散列到不同的值。但是，盐通常与密码一起存储在数据库中。所以假设我是攻击者，这就是我如何使用字典攻击来攻击盐（注意在这个例子中，为了简洁起见，我没有写出 128 位哈希或盐）：

user_pw = 'blowfish'

Given:
email = 'blah@blah.com'
hash = '1234567890'
salt = '0987654321'

function attack(){
  for each(word in dictionary)
    md5( word * salt ) == hash ? cracked_one(email, word)
}

我知道这可以防止黑客使用彩虹表...但似乎无法防止字典攻击。我想您可以在哈希算法中添加其他内容，但出于安全考虑，我们必须假设攻击方法是已知的。

因此，加盐似乎可以防止黑客找出哪些密码可能是字典密码（多个用户拥有的密码）并防止彩虹攻击......但不能防止字典攻击。

这是一个正确的分析吗？有什么更好的安全建议吗？

谢谢！

【问题讨论】：

标签： security authentication hash salt

【解决方案1】：

您的逻辑是合理的，但实际上，只要有足够的计算能力和时间，就无法抵御字典/暴力攻击。

【讨论】：

也许有足够的力量和时间，没有针对暴力攻击的保护。但是，使用不在任何字典中的密码足以保护您免受任何字典攻击。
好点，但培训用户选择安全密码本身就是一项努力

【解决方案2】：

没有盐，攻击者可以为他的字典中的每个单词生成哈希，然后针对你的密码列表运行新字典

使用 salt，每个密码都使用随机字符串进行哈希处理，因此即使使用先前的哈希字典知识，他仍然必须重新创建一个新的哈希字典，其中包含数据库中每个不同 salt 的 salt。

只需将字典表视为彩虹表的子集（一小部分）。虽然彩虹表可以包含数十亿个条目，但字典包含“已知单词”，因此最多可能有几百万个条目。

彩虹表对盐失败的原因是因为重新创建过程将是“数十亿个条目”的重新计算，而字典攻击仍然是“几百万个条目”。盐只是阻止预先计算的值

【讨论】：

我不确定这是否完全正确。蛮力意味着通过可能的密码空间进行顺序或随机搜索。使用盐，攻击者仍然可以将盐和哈希应用于字典，但他们必须选择一个盐值来执行此操作，而且他们不会提前任意获得该值，因此他们必须计算它在飞行中。

【解决方案3】：

没有什么可以阻止攻击者仅仅猜测密码。

Salt 会迫使攻击者在每个用户（实际上是每个盐）基础上对字典进行哈希处理，从而使其变得更加困难。

为了提高安全性，可调整的哈希函数是您的最佳选择。加快每次散列的时间，使字典攻击在攻击者可能拥有的任何硬件上都不切实际。

基本上，read this。

【讨论】：

可调散列方法听起来就像键强化。任何哈希都可以通过反复运行以这种方式进行调整。
是的，它是关键强化和相关技术。不过，好文章，尤其是关于 SRP 的部分。谢谢。

【解决方案4】：

Salt 不能防止字典攻击，只是预先计算的字典攻击。特别是，它可以防止彩虹表 (http://en.wikipedia.org/wiki/Rainbow_table) 并确保破解一个用户的密码不会自动让您破解任何共享该密码的用户。

我链接到的文章提到了一些改进盐渍的方法，包括加强键 (http://en.wikipedia.org/wiki/Key_strengthening)。

【讨论】：

似乎最大的区别在于，通过使用盐，攻击者基本上必须为每个盐或用户计算一个新的字典或彩虹表。你知道计算一百万字的彩虹表需要多长时间吗？（不在这里寻找确切的答案）
不是个人，但project-rainbowcrack.com/table.htm 说你不需要自己制作：你可以下载他们的。更糟糕的是，破解者正在利用 NVidia Cuda GPU 来加速他们的工作。即使按照现代标准，这些彩虹表也很大，因此将它们乘以低至 4G（32 位）就足以使存储所有可能的彩虹表完全不可行，忘记生成成本。
这对某些人来说可能很明显，但应该注意的是，加盐可以防止对哈希值的攻击，而不是密码本身（即攻击者已经可以访问数据库，哈希值是明文传输的）等）。
@dsatch Salting 可防止从哈希中获取密码，然后在其他站点使用该密码。或者，更确切地说，这样做的成本要高得多。
可以的。我的观点有点不同——OP提到它“似乎不能防止字典攻击”。我想明确一点，任何人都可以字典攻击你的前端，而不用担心盐。 Salting 正在保护您存储此类密码的方式。

【解决方案5】：

没错。如果有人得到了密码材料，字典攻击就会奏效。

为了防止这种情况：

确保您的密码不会受到字典攻击。
确保您的密码文件 (/etc/shadow) 只有 root 才能读取。

【讨论】：

事后看来，这可能是一个明显的问题，但是有没有一个选项可以拒绝在字典中找到的密码？我也没有专门询问 Unix 变体。
@Steven Sudit：您可以为此目的使用cracklib
当然可以，但这是否已集成到密码更改系统中？
如果 pam_cracklib.so 包含在 PAM 堆栈中，则集成。