php - 第二种意见的安全性优势，我通过 postgresql 散列和加盐用户密码的计划是否存在缺陷？

Question

这是我的计划和目标:

总体目标:

• 具有一定程度的简单性和数据库到数据库可转移性的安全性，因为我不是专家，可能会把它搞砸，而且我不想让很多用户重置他们的密码。
• 轻松删除用于发布“已删除”测试数据数据库的密码。 (例如，我希望能够使用 postgresql 语句将所有密码简单地重置为简单的内容，以便测试人员可以自己使用该测试数据)。

计划:

散列密码

帐户创建会永久记录创建帐户时使用的原始电子邮件。

• 使用全局盐，例如“90fb16b6901dfceb73781ba4d8585f0503ac9391”。
• 使用帐户特定盐，即创建帐户时使用的原始电子邮件，例如“my.account@example.com”。
• 使用用户的密码，例如“password123”(我会在注册表单中警告弱密码)

全局盐、帐户特定盐和密码的组合通过 postgresql 中的某种散列方法进行散列(无法在 postgresql 中找到散列函数的文档，但能够使用 sha-2 或类似的东西如果我能找到它就好了)。

哈希被保存在数据库中。

恢复帐户

要更改密码，他们必须通过标准密码重置(并且重置电子邮件会发送到原始电子邮件以及他们设置的最新帐户电子邮件)。

缺陷？

我需要解决这个问题吗？是否有在 postgresql 中完全进行散列的最佳实践？

Answer 1

我不会将用户数据作为盐的一部分。例如，如果管理员需要更改用户的电子邮件地址(不知道用户密码的人能够重新生成哈希)怎么办？使用帐户创建时间戳或存储在记录中的随机值，或其他一些不可变的用户特定值。