PHP password_hash() / bcrypt
PHP password_hash() / bcrypt
我正在查看 bcrypt 哈希算法。
我对 password_hash() 的第一次测试：
echo password_hash("123", PASSWORD_BCRYPT, array( "salt" => "1234567890123456789012" ));
echo password_hash("123", PASSWORD_BCRYPT, array( "salt" => "1234567890123456789012xxxxxxxxxxxxxxx" ));
两者都会 return '$2y$10$123456789012345678901uiaLpJxTpf6VbfI5NADlsRsfvEm6aq9C'。
- 为什么盐存储在散列中？这对我来说毫无意义。从数据库中获取哈希值的攻击者如果不知道盐值，就无法对它们做任何事情。
- 为什么我用两种不同的盐得到相同的哈希值？是否只有前 22 个字符用于传递给函数的盐？
非常感谢！
salt 不是秘密，它通常与哈希一起存储在数据库中，也可以像 password_hash 那样直接存储在哈希中。
盐创造了唯一性，所以散列不能轻易地被彩虹 tables 或字典之类的东西破解，除了使散列更独特之外，它并没有真正增加安全性所以 运行 字典或 table 与散列不匹配，因为它还包含盐。
如果省略盐，password_hash() 将为每个散列的密码生成一个随机盐。这是预期的操作模式，您不应提供自己的盐。
PHP7 实际上会产生一个警告，告诉您使用 salt 选项已被弃用。
传递的盐至少需要 22 个字符，但大多数底层算法（如 bcrypt）不会使用整个盐，请参阅 this answer 了解更多信息
盐不是你必须努力保密的东西。即使知道，它们的保护也是有效的。 https://crackstation.net/hashing-security.htm
The salt does not need to be secret. Just by randomizing the hashes, lookup tables, reverse lookup tables, and rainbow tables become ineffective. An attacker won't know in advance what the salt will be, so they can't pre-compute a lookup table or rainbow table. If each user's password is hashed with a different salt, the reverse lookup table attack won't work either.
由于您似乎使用的是固定盐值，请注意：
A common mistake is to use the same salt in each hash. Either the salt is hard-coded into the program, or is generated randomly once. This is ineffective because if two users have the same password, they'll still have the same hash. An attacker can still use a reverse lookup table attack to run a dictionary attack on every hash at the same time. They just have to apply the salt to each password guess before they hash it. If the salt is hard-coded into a popular product, lookup tables and rainbow tables can be built for that salt, to make it easier to crack hashes generated by the product.
我建议使用不带可选参数的 password_hash。默认函数被构建为高度安全，通过指定您自己的算法和选项，您可能会削弱其功能。
Caution It is strongly recommended that you do not generate your own salt for this function. It will create a secure salt automatically for you if you do not specify one.
编辑：这就是为什么在 bcrypt 中对盐保密毫无意义。
根据 this post，一个 8 个字符的密码有 3,025,989,069,143,040 种可能的组合。您通常应该将 bcrypt 的工作因数调整为需要 0.1 秒来散列密码。这意味着计算所有可能性需要 302,598,906,914,304 秒。即9,588千年.
我正在查看 bcrypt 哈希算法。
我对 password_hash() 的第一次测试：
echo password_hash("123", PASSWORD_BCRYPT, array( "salt" => "1234567890123456789012" ));
echo password_hash("123", PASSWORD_BCRYPT, array( "salt" => "1234567890123456789012xxxxxxxxxxxxxxx" ));
两者都会 return '$2y$10$123456789012345678901uiaLpJxTpf6VbfI5NADlsRsfvEm6aq9C'。
- 为什么盐存储在散列中？这对我来说毫无意义。从数据库中获取哈希值的攻击者如果不知道盐值，就无法对它们做任何事情。
- 为什么我用两种不同的盐得到相同的哈希值？是否只有前 22 个字符用于传递给函数的盐？
非常感谢！
salt 不是秘密，它通常与哈希一起存储在数据库中，也可以像 password_hash 那样直接存储在哈希中。
盐创造了唯一性，所以散列不能轻易地被彩虹 tables 或字典之类的东西破解，除了使散列更独特之外，它并没有真正增加安全性所以 运行 字典或 table 与散列不匹配，因为它还包含盐。
如果省略盐，password_hash() 将为每个散列的密码生成一个随机盐。这是预期的操作模式，您不应提供自己的盐。
PHP7 实际上会产生一个警告，告诉您使用 salt 选项已被弃用。
传递的盐至少需要 22 个字符，但大多数底层算法（如 bcrypt）不会使用整个盐，请参阅 this answer 了解更多信息
盐不是你必须努力保密的东西。即使知道，它们的保护也是有效的。 https://crackstation.net/hashing-security.htm
The salt does not need to be secret. Just by randomizing the hashes, lookup tables, reverse lookup tables, and rainbow tables become ineffective. An attacker won't know in advance what the salt will be, so they can't pre-compute a lookup table or rainbow table. If each user's password is hashed with a different salt, the reverse lookup table attack won't work either.
由于您似乎使用的是固定盐值，请注意：
A common mistake is to use the same salt in each hash. Either the salt is hard-coded into the program, or is generated randomly once. This is ineffective because if two users have the same password, they'll still have the same hash. An attacker can still use a reverse lookup table attack to run a dictionary attack on every hash at the same time. They just have to apply the salt to each password guess before they hash it. If the salt is hard-coded into a popular product, lookup tables and rainbow tables can be built for that salt, to make it easier to crack hashes generated by the product.
我建议使用不带可选参数的 password_hash。默认函数被构建为高度安全，通过指定您自己的算法和选项，您可能会削弱其功能。
Caution It is strongly recommended that you do not generate your own salt for this function. It will create a secure salt automatically for you if you do not specify one.
编辑：这就是为什么在 bcrypt 中对盐保密毫无意义。
根据 this post，一个 8 个字符的密码有 3,025,989,069,143,040 种可能的组合。您通常应该将 bcrypt 的工作因数调整为需要 0.1 秒来散列密码。这意味着计算所有可能性需要 302,598,906,914,304 秒。即9,588千年.