我知道bcrypt比其他方法更安全，但仍然会让您遇到需要使用密码的情况。 如果包含在散列字符串中的盐不需要单独存储在数据库中。每次我需要创建一个新的哈希，也意味着一个新的盐，我是否必须获取所有密码，提取salt并检查新的哈希值是否已经不存在，以防我的数据库密码？ 为了便于比较，将盐分开直接存储不会更容易吗？如果是的话，我不明白：我需要在PHP中使用bcrypt的独特盐吗？
这个网站似乎做在简要说明一份体面的工作：http://michaelwright.me/php-password-storage
快速回答：
1）你并不需要存储的盐。
2）如果您为每个密码使用独特的盐，则不需要更新所有哈希。
3）我不是加密专家，但是当你为每个用户/密码使用独特的salt时，攻击者必须为每个用户使用一组不同的彩虹表。在整个站点使用相同的salt值意味着每个用户的密码都会受到相同散列表的影响。在过去（无论好坏），我使用了用户上次登录时间和/或最后一个IP的函数作为密码的盐值。
例如（伪代码）$ password = hash（hash（$ _ POST ['password']）。hash（$ row ['last_login']））;
4）我会推迟“为什么bcrypt更好？”向有关这些事情更了解的人提问。这个答案可能有所帮助：How do you use bcrypt for hashing passwords in PHP?
我实际上会不同意柯蒂斯马顿的几个事情的答案。
当你使用bcrypt进行散列时，salt直接存储在散列内部，所以你不需要单独存储它。我不确定他的意思是不需要存储它，因为没有盐的散列是完全无用的。需要salt来验证密码与哈希值。
我同意这一点。如果您要更新一个密码，则不需要全部更新它们。事实上，这是不可能的，因为你（希望）不知道任何其他用户的密码。
你不需要经历痛苦才能获得独特的盐。如果是这样的话，你可以使用uniqid，但问题在于它的输出是可预测的。可预测性在密码学中是一件坏事。相反，您要做的是尽可能使用伪随机盐尽可能接近（即使用/dev/random而不是/dev/urandom）。如果你有十亿用户，你可能会得到一个或两个完全相同的盐，但严重的是，这是一个如此大的问题？它所做的只是让人们有可能将这两个特定密码的密码强制为十亿次以上，我怀疑它甚至有可能发生冲突。不要过度紧张。使盐成为随机的，而不是唯一的。使用诸如上次登录时间或IP地址之类的东西只会从随机性中消失。
至于SHA512和河豚之间的比较，看到这里SHA512 vs. Blowfish and Bcrypt