加盐算法强度
这 3 种制造盐的方法有哪些优点/缺点？
$salt = md5($password);
$salt = sha1(md5($password));
$salt = generate_random_number();
计算哈希值：
$hash = sha1($salt + $password);
What are the advantages / disadvantages of those 3 methods to create a salt?
$salt = md5($password);
$salt = sha1(md5($password));
$salt = generate_random_number();
Computing hash:
$hash = sha1($salt + $password);
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
盐
要回答这个问题，重要的是要知道盐是什么。
盐是针对预先计算表的攻击而设计的。例如彩虹桌。彩虹表是巨大的表，包含所有可能的密码变体，直至一定长度。 （使用巧妙的内存/时间权衡。）
如果攻击者只想破解一个密码，他们就没有优势。
则上述陈述不成立
使用彩虹表的攻击者通常希望破解尽可能多的帐户。
您的哪种方法最安全？
除了第三种之外，您的所有方法都是不安全。这是因为使用任何其他方法都允许攻击者为整个数据库计算彩虹表。
因为盐依赖于密码。也不要使其依赖于用户名，这仍然允许攻击者为 100 个最常见的用户名创建彩虹表。
请记住，
Salts
To answer this question it's important to know for what salts are.
Salts are designed against attacks with pre-calculated tables. For example rainbow tables. Rainbow tables are huge tables with all possible password variations up to a certain length. (Using a clever memory/time tradeoff.)
If the attacker only wants to crack a single password, they don't offer an advantage.
The statement above is not true if
Attackers using rainbow tables usually want to crack as many accounts as possible.
Which of your methods is most secure?
All of your methods except the third are insecure. This is because using any of the other methods allows the attacker to calculate a rainbow-table for your whole database.
Because the salt is dependent on the password. Don't make it dependent on the username either, this would still allow an attacker to create a rainbow table for the 100 most common usernames.
Keep in mind
前两种方法没有什么价值。加盐的全部意义在于，相同的密码并不总是产生相同的加密/散列字符串。
如果您使“盐”仅依赖于密码，则相同的密码将始终产生相同的哈希值。所以基本上结果与使用稍微不同的哈希函数但不加任何盐是一样的。
使用第三种方法，具有相同密码的两个用户通常会获得不同的盐，并且密码的哈希版本对于两个用户来说看起来会有所不同。通过哈希值很难判断它们具有相同的密码。
The first two methods are worthless. The whole point of salting is that the same password does not always result in the same encrypted/hashed string.
If you make the "salt" dependent on just the password, the same password will always result in the same hash. So basically the result is the same as if you'd use a slightly different hash function without any salt.
With the third method two users with the same password will usually get a different salt and the hashed version of the password will look different for both users. It will be hard to tell by the hashes that they both have the same password.
严格来说，您只有一种加盐方法，即计算哈希值。前三行是生成盐的不同方法。
因此，盐可以阻止预先计算的查找表发现密码。它应该是由某人存储的固定值，最好对于被散列的纯文本来说是唯一的。
最安全的方法是使用加密安全随机数生成器来生成盐，然后将盐与密码一起存储。
如果您创建的盐是密码的 MD5，那么它必须与散列和加盐密码值一起存储，这意味着您有一个未加盐的散列，它很容易受到预先计算的查找表的影响，除非您计划每次都计算它是一个小的性能影响。通过采用 MD5 哈希值的 SHA 哈希值，您可以减少纯文本值的可能性，因为 MD5 哈希值的数量是固定长度的，因此它们的数量是有限的。这意味着彩虹表查找可能比真正随机的盐有更大的成功机会。
所以请使用随机盐。
Well strictly speaking you only have one salting method, where you calculate the hash. The first three lines are different ways of generating a salt.
So a salt is there to stop precomputed lookup tables from discovering passwords. It should be a fixed value stored someone that is, preferably, unique to the plain text being hashed.
The most secure would be to use a cryptographically secure random number generator to produce a salt which is then stored along side the password.
If you created a salt which was an MD5 of the password then it would have to stored alongside the hashed and salted password value, which means you have an unsalted hash which is vulnerable to precomputed lookup tables, unless you plan to calculate it every time which is a small performance hit. By taking a SHA hash of an MD5 hash you're reducing the possibility of the plain text values, as there's a finite number of MD5 hash values as they are fixed length. This would mean that a rainbow table lookup might have a greater chance of success than a truly random salt.
So use the random salt please.
考虑彩虹表的一种有用方法是，它们可以为任何只有一个输入的单向（或“活板门”）函数构建。也就是说，如果您对所有密码使用相同的函数 F：hash = F(password)。 F 可以是 MD5 或 SHA1 或其他。
现在让我们看看盐。您使用加盐函数 G，hash = G(salt，password)。如果你的数据库中的所有密码都使用相同的盐，你可以构造一个函数G，其中G（密码）= F（“你的盐”，密码），所以有一个单一的输入函数，因此你可以构建一个彩虹表。
如果盐取决于密码怎么办？假设salt = I(密码)，我们可以构建J(密码) = G(I(密码)，密码)，单个输入函数，因此可以构建彩虹表。
因此，每个密码都需要有自己的盐。这意味着攻击者在破解您的所有密码所需的时间内只能破解一个。
A useful way to think of rainbow tables is that they can be built for any one-way (or "trapdoor") function that only has one input. That is, if you use the same function, F, for all your passwords: hash = F(password). F could be MD5 or SHA1 or whatever.
Now lets look at salts. You use a salted function G, hash = G(salt, password). If all passwords in your database use the same salt, you can construct a function G, where G(password) = F("your salt", password), so there is a single input function, and thus you can build a rainbow table.
What if the salt depends on the password? Say the salt = I(password), we can build J(password) = G(I(password), password), a single input function, so rainbow tables can be built.
So, each password needs to have its own salt. This means that in the time it would take an attacker to crack all of your passwords, they can only crack one.