我不太明白盐对密码的作用。据我所知，它的主要用途是阻止彩虹桌的攻击。然而，我所看到的实现这一点的方法似乎并没有真正使问题变得更难。
我看过很多教程，建议盐可以这样使用:
$hash = md5($salt.$password)
原因是哈希现在映射的不是原来的密码，而是密码和盐的组合。但是输入$salt=foo和$password=bar和$hash=3858f62230ac3c915f300c664312c63f。现在有一张彩虹表的人可以反向哈希，得到输入“foobar”。然后他们可以尝试所有的密码组合(f, fo, foo，…)Oobar, obar, bar, ar)获取密码可能还需要几毫秒的时间，但仅此而已。
我看到的另一种用法是在我的linux系统上。在/etc/shadow中，散列密码实际上与salt一起存储。例如，salt为“foo”，password为“bar”将哈希为$1$foo$te5SBM.7C25fFDu6bIRbX1。如果黑客以某种方式获得了这个文件，我不知道盐有什么用途，因为te5SBM的反向哈希。已知7C25fFDu6bIRbX包含“foo”。
感谢大家对这件事的解释。
编辑:谢谢你的帮助。总结一下我的理解，salt使散列密码更加复杂，从而使它不太可能存在于预先计算的彩虹表中。我之前误解的是，我假设所有哈希表都存在一个彩虹表。
我正在寻找一个好的方法来应用盐，发现这篇优秀的文章与示例代码:
http://crackstation.net/hashing-security.htm
作者建议对每个用户使用随机salt，这样访问salt就不会使整个哈希列表容易被破解。
To Store a Password:
Generate a long random salt using a CSPRNG.
Prepend the salt to the password and hash it with a standard
cryptographic hash function such as SHA256.
Save both the salt and the hash in the user's database record.
To Validate a Password :
Retrieve the user's salt and hash from the database.
Prepend the salt to the given password and hash it using the same hash function.
Compare the hash of the given password with the hash from the database. If they
match, the password is correct. Otherwise, the password is incorrect.
大多数打破基于哈希的加密的方法依赖于暴力攻击。彩虹攻击本质上是一种更有效的字典攻击，它的设计目的是使用低成本的数字存储来创建一个映射，将大量可能的密码子集映射到哈希表，并促进反向映射。这种攻击之所以有效，是因为许多密码要么相当短，要么使用几种基于单词的格式模式之一。
Such attacks are ineffective in the case where passwords contain many more characters and do not conform to common word based formats. A user with a strong password to start with won't be vulnerable to this style of attack. Unfortunately, many people do not pick good passwords. But there's a compromise, you can improve a user's password by adding random junk to it. So now, instead of "hunter2" their password could become effectively "hunter2908!fld2R75{R7/;508PEzoz^U430", which is a much stronger password. However, because you now have to store this additional password component this reduces the effectiveness of the stronger composite password. As it turns out, there's still a net benefit to such a scheme since now each password, even the weak ones, are no longer vulnerable to the same pre-computed hash / rainbow table. Instead, each password hash entry is vulnerable only to a unique hash table.
Say you have a site which has weak password strength requirements. If you use no password salt at all your hashes are vulnerable to pre-computed hash tables, someone with access to your hashes would thus have access to the passwords for a large percentage of your users (however many used vulnerable passwords, which would be a substantial percentage). If you use a constant password salt then pre-computed hash tables are no longer valuable, so someone would have to spend the time to compute a custom hash table for that salt, they could do so incrementally though, computing tables which cover ever greater permutations of the problem space. The most vulnerable passwords (e.g. simple word based passwords, very short alphanumeric passwords) would be cracked in hours or days, less vulnerable passwords would be cracked after a few weeks or months. As time goes on an attacker would gain access to passwords for an ever growing percentage of your users. If you use a unique salt for every password then it would take days or months to gain access to each one of those vulnerable passwords.
As you can see, when you step up from no salt to a constant salt to a unique salt you impose a several orders of magnitude increase in effort to crack vulnerable passwords at each step. Without a salt the weakest of your users' passwords are trivially accessible, with a constant salt those weak passwords are accessible to a determined attacker, with a unique salt the cost of accessing passwords is raised so high that only the most determined attacker could gain access to a tiny subset of vulnerable passwords, and then only at great expense.
这正是现在的情况。您永远无法完全保护用户不受糟糕密码选择的影响，但您可以提高泄露用户密码的成本，使泄露一个用户密码的代价变得高昂。
当破解单个密码时，公共盐不会使字典攻击更加困难。正如您所指出的，攻击者可以访问散列密码和salt，因此在运行字典攻击时，她可以在试图破解密码时简单地使用已知的salt。
公共盐做了两件事:使破解大量密码列表更加耗时，并使使用彩虹表变得不可行的。
To understand the first one, imagine a single password file that contains hundreds of usernames and passwords. Without a salt, I could compute "md5(attempt[0])", and then scan through the file to see if that hash shows up anywhere. If salts are present, then I have to compute "md5(salt[a] . attempt[0])", compare against entry A, then "md5(salt[b] . attempt[0])", compare against entry B, etc. Now I have n times as much work to do, where n is the number of usernames and passwords contained in the file.
To understand the second one, you have to understand what a rainbow table is. A rainbow table is a large list of pre-computed hashes for commonly-used passwords. Imagine again the password file without salts. All I have to do is go through each line of the file, pull out the hashed password, and look it up in the rainbow table. I never have to compute a single hash. If the look-up is considerably faster than the hash function (which it probably is), this will considerably speed up cracking the file.
但是如果密码文件被加了盐，那么彩虹表就必须包含“salt”。pre-hashed密码”。如果盐是完全随机的，这是不太可能的。在我的常用预哈希密码列表(彩虹表)中，我可能会有“hello”、“foobar”和“qwerty”这样的东西，但我不会预先计算“jX95psDZhello”或“LPgB0sdgxfoobar”或“dZVUABJtqwerty”这样的东西。这将使彩虹桌大得令人望而却步。
因此，salt将攻击者减少到每行每次尝试一次计算，当加上足够长、足够随机的密码时，(一般来说)是不可破解的。
