我在阅读了一些关于 php 会话管理的主题后开始了这个安全讨论，看看：https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2
引用章节：胡椒还是不胡椒？
一个更好的解决方案（如果使用硬件分离尤其有用）是在将哈希插入数据库之前对其进行加密。有了这种保护措施，即使攻击者找到了转储所有数据库表的方法，他们也必须首先解密哈希值，然后才能开始破解它们。由于PHP和数据库位于不同的硬件上，这变得更加安全。
在本文中，共享了指向 https://github.com/defuse/php-encryption 的链接...
到目前为止，我只使用 password_hash（） 将密码存储在数据库中。是否建议加密哈希本身？你有什么意见？
感谢您的想法！
使用适当的哈希算法进行哈希通常足以保护密码，但之后加密（而不是编码）哈希确实更安全。
使用服务器端密钥加密哈希时，攻击者必须在服务器上获得其他权限才能获取此密钥（没有密钥，哈希值一文不值）。获得对数据库的只读访问权限比获得服务器上的权限要容易得多。例如SQL注入，丢弃备份，丢弃的服务器，...在所有这些情况下，加密将保护哈希。
在此答案中，您可以找到更多信息，或者您可能想查看我关于安全存储密码的教程的结尾。
是否建议对哈希本身进行编码？你有什么意见？
不，password_hash()/password_verify()就足够了。需要脊椎水龙头级安全性的人可以参考本文的这一部分以获取指导，以避免在试图提高安全性时意外地射中自己的脚，但一般来说，如果您在 2016 年使用 bcrypt，那么您没问题。
除非您的网站和数据库有单独的服务器，否则此策略的安全性收益为零。如果我能进入你的数据库，我几乎可以肯定能进入你的文件系统，并恢复加密密钥。
如果您确实有单独的硬件，并且您使用经过身份验证的加密库（例如 Defuse Security 提供的加密库），请随意使用它。只要知道对于大多数用例来说，这不是必需的，因为密码哈希API提供了针对现代密码破解的良好安全性。
在PHP的更高版本中，它们还将支持Argon2。如果你要过火，请切换到它，而不是增加你的协议的复杂性。
（此外，它是加密的，而不是编码的。
需要加密哈希。攻击者必须反转哈希才能找到正确的明文（用户密码）。这相当于找出正确的加密密钥。哈希就足够了。加上盐显然，否则您的架构容易受到彩虹表攻击