为什么盐会使字典攻击“不可能”？
可能重复：
需要一些帮助了解密码salt
更新：请注意，我不是问盐是什么，彩虹表是什么，字典攻击是什么，盐的目的是什么。 我在查询：如果你知道用户salt和hash，是不是很容易计算他们的密码？
我理解这个过程，并在我的一些项目中自己实现它。
s = random salt
storedPassword = sha1(password + s)
在你存储的数据库中：
username | hashed_password | salt
我所见过的每一次盐析实施都会在密码末尾添加salt，或者开始：
hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)
因此，一个值得他的盐的黑客的字典攻击（哈哈）只需运行上面列出的常见组合中的每个关键字与储存的盐。
上面描述的实现当然只是为黑客添加了另一个步骤，而没有真正解决潜在的问题？ 有什么替代方法来解决这个问题，或者我误解了这个问题？
我认为唯一能做的就是有一个秘密混合算法，它将盐和密码以随机模式绑定在一起，或者将其他用户字段添加到散列过程中，这意味着黑客必须有权访问数据库和代码才能花边他们的字典攻击证明富有成效。 （更新，正如在评论中指出的那样，最好假定黑客可以访问你的所有信息，所以这可能不是最好的）。
让我举一个例子，说明我建议黑客用密码和哈希列表破解用户数据库：
来自我们黑客入侵的数据库
RawPassword (not stored) | Hashed | Salt
--------------------------------------------------------
letmein WEFLS... WEFOJFOFO...
常用密码字典：
Common Password
--------------
letmein
12345
...
对于每个用户记录，循环使用公用密码并对其进行散列处理
for each user in hacked_DB
salt = users_salt
hashed_pw = users_hashed_password
for each common_password
testhash = sha1(common_password + salt)
if testhash = hashed_pw then
//Match! Users password = common_password
//Lets visit the webpage and login now.
end if
next
next
我希望这能更好地说明我的观点。
假设有10,000个通用密码和10,000个用户记录，我们需要计算100,000,000个哈希以尽可能多地发现用户密码。 这可能需要几个小时，但这不是一个真正的问题。
破解理论更新
我们将假定我们是一个损坏的网络主机，它可以访问SHA1哈希和盐的数据库，以及您的算法来混合它们。 该数据库有10,000个用户记录。
该网站声称能够使用GPU每秒计算2,300,000,000个SHA1哈希值。 （在现实世界中情况可能会变慢，但现在我们将使用引用的数字）。
（（（95 ^ 4）/ 2300000000）/ 2）* 10000 = 177秒
给定全部95个可打印的ASCII字符，最大长度为4个字符，除以计算速率（可变），除以2（假设发现密码的平均时间平均需要50％的置换）用户需要177秒来计算长度小于等于4的所有用户密码。
让我们调整一下现实主义。
（（（36 ^ 7）/ 1000000000）/ 2）* 10000 = 2天
假设不区分大小写，密码长度小于等于7，只有字母数字字符，需要4天才能解决10000条用户记录，并且我将算法的速度减半以反映开销和非理想情况。
认识到这是线性蛮力攻击很重要，所有计算都是彼此独立的，因此对于多个系统来说这是一个完美的任务。 （IE容易设置两台计算机从不同的端点运行攻击，执行时间只有一半）。
考虑到递归散列密码1,000次的情况，以使得该任务在计算上更加昂贵：
（（（36 ^ 7）/ 1 000 000 000）/ 2）* 1000秒= 10.8839117小时
这表示最大长度为7个字母数字字符，对于一个用户，引用数字的执行速度不到一半时的速度。
递归散列1000次有效地阻止了一次全面攻击，但针对用户数据的攻击依然是脆弱的。
是的，sha1（salt |密码）只需要3天。 这就是为什么好的密码存储算法使用1000次迭代散列：您需要8年。
它不会停止字典攻击。
它所做的就是阻止那些设法获取密码文件副本的人使用彩虹表来找出哈希中的密码。
不过，最终它可能会被蛮横逼迫。 该部分的答案是强制用户不要使用字典中的单词作为密码（例如至少一个数字或特殊字符的最低要求）。
更新 ：
我应该早些提到这一点，但是一些（大多数？）密码系统为每个密码使用不同的盐，可能与密码本身一起存储。 这使得单个彩虹桌无用。 这就是UNIX crypt库的工作方式，而现代的类UNIX操作系统已经使用新的散列算法扩展了这个库。
我知道在新版本的GNU crypt中添加了对SHA-256和SHA-512的支持。
更准确地说，字典攻击，即尝试使用穷举列表中的所有单词的攻击，并非“不可能”，但它变得不切实际 ：每一点盐都需要双倍的存储和计算量。
这与预先计算的字典式攻击不同，例如涉及彩虹表的攻击，其中盐是否秘密并不重要。
例如：对于64位盐（即8字节），您需要在字典攻击中检查264个额外的密码组合。 用一个包含20万字的字典，你将不得不作出
200,000 * 264 = 3.69 * 1024
在最坏的情况下进行测试 - 而不是没有盐的20万次测试。
使用salt的另一个好处是攻击者无法预先计算他的字典中的密码哈希值。 这只会花费太多时间和/或空间。
更新
您的更新假定攻击者已经知道盐（或已经被盗）。 这当然是不同的情况。 尽管如此，攻击者不可能使用预先计算的彩虹表。 这里最重要的是哈希函数的速度。 为了使攻击不切实际，散列函数需要缓慢。 MD5或SHA在这里并不是很好的候选者，因为它们被设计成快速，更好的散列算法候选者是Blowfish或它的一些变体。
更新2
关于确保密码散列的问题，一般都会有很好的解读（远远超出原始问题，但仍然很有趣）：
足够的彩虹表：你需要知道的安全密码方案
文章的推论：使用由bcrypt （基于Blowfish）或Eksblowfish创建的盐渍散列，允许您使用可配置的安装时间使散列变慢。
链接地址: http://www.djcxy.com/p/21583.html