在阅读了一些关于PHP会话管理的主题之后，我开始了这个安全性讨论，请看：https://paragonie.com/blog/2015/04/secure authentication php with long term persistence title.2

引自第章：去胡椒还是不去胡椒？

A much better solution, which is especially useful if you employ hardware separation, is to encrypt the hashes before you insert them in your database. With this safeguard in place, even if an attacker finds a way to dump all of your database tables, they first have to decrypt the hashes before they can even begin to crack them. With the PHP and the database on separate hardware, this becomes much more secure.

号

在本文中，到https://github.com/defuse/php-encryption的链接是共享的…

到目前为止，我只使用密码hash()将密码存储在数据库中。建议加密哈希本身吗？你怎么看？

谢谢你的想法！

使用适当的散列算法散列通常足以保护密码，但对散列进行加密(而不是编码)后确实更安全。

当使用服务器端密钥加密散列时，攻击者必须在服务器上获得额外的特权才能获取此密钥(如果没有该密钥，散列将毫无价值)。获取对数据库的只读访问要比获取服务器上的特权容易得多。例如SQL注入、丢弃的备份、丢弃的服务器…在所有这些情况下，加密将保护哈希。

在这个答案中，您可以找到更多的信息，或者您可能想看看我关于安全存储密码的教程的末尾。

Is it recommendable to encode the hash itself? What's your opinion?

号

不，password_hash()/password_verify()就足够了。需要脊椎穿刺级别安全的人可以参考文章中的这一部分以获得指导，以避免无意中在脚上开枪，试图提高他们的安全性，但一般来说，如果您在2016年使用BCRYPT，那么您就没事了。

除非您的网站和数据库有单独的服务器，否则此策略的安全收益为零。如果我能进入你的数据库，我几乎可以肯定地进入你的文件系统，并恢复加密密钥。

如果您确实有单独的硬件，并且使用了经过身份验证的加密库(如defuse security提供的库)，那么一定可以随意使用它。只需知道，对于大多数用例来说，这是不必要的，因为密码散列API为防止现代密码破解提供了相当好的安全性。

在PHP的较新版本中，它们还将支持argon2。如果你想做得过火，那就换一种方式，而不是增加协议的复杂性。

(同样，它是加密的，而不是编码的。)

根本不需要加密哈希。攻击者必须反向散列才能找到正确的明文(用户密码)。这相当于找出加密的正确密钥。散列就足够了。显然，加上salt，否则您的模式容易受到彩虹表攻击。