为什么盐会让字典攻击变得“不可能”？
更新: 请注意，我不是在问盐是什么，彩虹桌是什么，字典式攻击是什么，或者盐的用途是什么。我在问: 如果您知道用户 salt 和 hash，那么计算他们的密码不是很容易吗？
我理解这个过程，并且在我的一些项目中自己实现它。
s = random salt
storedPassword = sha1(password + s)
在存储的数据库中:
username | hashed_password | salt
我见过的每一个 salting 实现都会在密码的末尾或者开头添加 salt:
hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)
因此，值得一试的黑客字典式攻击(哈哈)只需将每个关键字与上述常见组合中储存的盐进行比对即可。
当然，上面描述的实现只是为黑客增加了另一个步骤，而没有实际解决根本问题？有什么办法可以解决这个问题，还是我误解了这个问题？
我唯一能想到的办法就是使用一种秘密混合算法，将 salt 和 password 以随机模式混合在一起，或者在散列过程中添加其他用户字段，这意味着黑客必须访问数据库 AND 代码，将它们混合在一起，才能证明字典式攻击是有效的。(更新，正如在评论中指出的那样，最好假设黑客已经访问了你的所有信息，所以这可能不是最好的)。
让我举个例子来说明我是如何建议一个黑客利用密码和哈希表来黑进一个用户数据库的:
黑客数据库里的数据:
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)/230000000)/2) * 10000 = 177 几秒钟
给定一个95个可打印的 ASCII 字符的全部范围，最大长度为4个字符，除以计算速率(变量) ，除以2(假设发现密码的平均时间将平均需要50% 的排列) ，对于10,000个用户，计算出所有长度 < = 4的用户密码需要177秒。
让我们调整一下现实主义。
(((36 ^ 7)/100000000)/2) * 10000 = 2天
假设没有大小写敏感性，密码长度 < = 7，只有字母数字字符，需要4天才能解决10,000个用户记录，我已经将算法的速度减半，以反映开销和非理想情况。
重要的是要认识到，这是一个线性穷举法，所有的计算都是相互独立的，因此这是一个完美的任务，多个系统来解决。(IE 很容易设置2台计算机从不同的端运行攻击，可以减少一半的执行时间)。
考虑到递归散列密码1000次以增加这项任务的计算开销的情况:
((36 ^ 7)/1000000000)/2) * 1000 秒 = 10.8839117小时
这表示最大长度为7个字母数字字符，从 一个用户的引号图以不到一半的速度执行。
递归散列1000次有效地阻止了一次全面攻击，但是针对用户数据的攻击仍然很脆弱。
最佳答案