密码验证的这种实施方式看起来安全吗？

Question

我正在创建一个我需要对其进行安全身份验证的Web应用程序。通过阅读大量文章和帖子，我对实现有了以下结论。

1. FrontEnd Password Hashing：使用bcrypt，我将使用唯一的盐对纯文本密码进行哈希处理。该盐存储在每个用户的数据库中。然后，将这＃1盐渍哈希发送到API。

2. 后端密码哈希：使用PBKDF2，再次将＃1盐哈希与另一个唯一的盐进行哈希运算，生成＃2盐哈希，然后将其与＃2盐一起存储在数据库中。

因此，数据库总共包含＃2盐腌哈希，＃1盐和＃2盐。

因此，在发生授权时，然后使用＃1 salt哈希散列创建＃1 salted-hash的纯文本密码。然后转到API进行授权，我们从数据库中获取＃2 salt-hash以创建＃2 salted-hash，然后将其与数据库中的＃2 salted-hash进行比较以进行授权。

很抱歉，这个问题似乎很多余，但是我找不到有关该实现的任何答案。如果有人可以帮助我，那就太好了！

Answer 1

您看过Information Security Stack Exchange吗？例如。 this answer。

客户端密码哈希通常被认为是无用且不必要的步骤，不会提高安全性。实际上，您的实现甚至可能会带来不必要的副作用，从而实际上降低了安全性：user enumeration

取决于您在授权过程中如何执行第一步，因此可能容易受到用户枚举的攻击。我假设如果您的数据库中找不到匹配的用户，则不会发送＃1盐：

1. Anon尝试使用与数据库中用户不匹配的用户名/电子邮件登录
2. 由于该用户不存在，所以没有相应的＃1盐要发送回去
3. 您的API不会发送回盐，或更糟糕的是，会发送“找不到用户”响应。无论哪种方式，anon现在都知道此用户名/电子邮件没有帐户

也可以通过其他方式工作：

1. Anon尝试使用与用户名/电子邮件不匹配的用户名/电子邮件登录您数据库中的用户
2. 由于此用户确实存在，因此API会发回该用户的＃1盐
3. Anon现在知道此用户名/电子邮件具有一个帐户

为了避免此用户枚举，如果找不到匹配的用户，您的API应该发送＃1盐even，甚至更多，它应该始终发送same salt以响应相同的用户名/ email，否则可能会发生：

1. Anon尝试使用与数据库中用户不匹配的用户名/电子邮件登录
2. 由于该用户不存在，所以没有相应的＃1盐要发送回去
3. 您的API发送回随机盐
4. Anon第二次尝试使用same用户名/电子邮件
5. 您的API发送回another随机盐与第一个不相同]
6. Anon可以推断出您的API包含两种盐，试图绕开用户枚举

为了解决，您必须想出一种方法，始终响应相同的用户名/电子邮件多次尝试发送相同的盐。似乎不必要的复杂性。这可能是客户端密码哈希不被认为是一件好事的原因之一。