加密已经散列的 BCrypt 密码是否过大？答案

【问题标题】：Is it overkill to encrypt an already hashed BCrypt password?加密已经散列的 BCrypt 密码是否过大？
【发布时间】：2018-10-12 22:14:22
【问题描述】：

我正在使用 BCrypt 在服务器端对我的密码进行哈希处理。在我将它存储在我的 MySQL 数据库中之前，加密我的散列 BCrypt 密码是否过大，或者将散列直接存储在数据库中就足够了？

website 建议在对密码进行哈希处理后对其进行加密：

只要攻击者可以使用哈希来检查密码是否猜测是对是错，他们可以运行字典或蛮力攻击哈希。下一步是在哈希中添加一个密钥这样只有知道密钥的人才能使用哈希来验证密码。这可以通过两种方式完成。哈希可以是使用像 AES 这样的密码加密，或者可以包含密钥使用 HMAC 等键控散列算法在散列中。

编辑：我正在用 Java 编码。我正在尝试衡量增加的保护层与读取和检索用户登录密码的速度性能是否值得。

【问题讨论】：

你希望通过加密获得什么？
你在使用 PHP 吗？
@LukeJoshuaPark 我正在尝试衡量增加的保护层与检索用户登录密码的速度性能是否值得
@RaymondNijland Java
如果你在同一个密码上运行生成 bcrypt 方法，你会得到不同的哈希值吗？在 PHP 中，这意味着 PHP 版本可以安全地防止暴力破解哈希攻击来获取密码。在 PHP 中使用 password_verify() 进行验证以检查密码是否正确。不知道这在 Java 中是如何工作的，因为谷歌搜索提供了一些不同的框架来在 Java 中使用 Bcrypt...

【解决方案1】：

这确实会提高安全性，但最好知道加密究竟能带来什么。

这种情况并不像人们想象的那么罕见，典型的场景是 SQL 注入、丢弃的备份、丢弃的服务器......

为了能够暴力破解密码，需要服务器端密钥，该密钥用于加密密码哈希。这意味着，能够从数据库中读取哈希值已经不够了，需要额外的权限才能从服务器读取密钥。在服务器上获得权限比读取数据库要困难得多。

Crackstation 是一个很好的咨询网站。在我自己的关于safely storing password 的教程结束时，我尝试解释这种密码哈希加密的细节。

【讨论】：