这个登录方案安全吗？

Question

以下是我为webapp登录方案所获得的内容。 数据库中存在两种盐和hmac（hmac（密码，盐1），盐2）。

当用户进入登录页面时，他获得了salt1。 如果他已激活javascript，而不是发送明文密码，它将发送hmac（密码，salt1）。 如果他没有javascript，则会发送明文密码。

因此，在服务器端，当收到登录请求时，我们首先检查发送的内容（passwordSent）对抗hmac（passwordSent，salt2）。如果它不起作用，我们会尝试hmac（hmac（passwordSent，salt1），salt2）。

有人访问数据库应该无法使用密码哈希登录，我不认为（但我可能错了）多重hmacs会减少哈希阻力。 有任何好的加密专家看到我可能做过的任何明显错误吗？

Answer 1

这看起来有点像安全性，如果你仍然接受来自客户端的纯文本密码，那么使用javascript在客户端散列密码是什么意思？

你没有提到这是否超过https，如果你没有使用https，那么你可能根本没有密码。如果您没有运行https，那么任何MITM都可以看到您发送的盐以及用于散列原始密码的javascript，因此您无法获得任何收益。

至于您对两种盐之间hmac碰撞可能性的担忧，这可能是非常不可能的（取决于您的哈希算法）以及您保持盐值的安全性。即使MD5发现了一些碰撞攻击并且有一组彩虹表，如果你保持盐非常安全，你也可以。

  

请各位，请停止尝试   实现自定义加密系统   除非你有背景资料   加密。你会搞砸了。   --Aaronaught

好吧！

Answer 2

对我来说听起来很牵强。如果这样做的目的是通过HTTP发送明文密码来防止“中间人”攻击，那么使用SSL。

客户端的哈希没有任何结果;除非salt实际上是一个nonce / OTP，并且 not 存储在数据库中，否则中间的人只需查看原始客户端发送的哈希值并将其传递给服务器。服务器不会知道差异。

如果有人抓住数据库，这应该会让人更难破解，但事实并非如此。如果散列函数很便宜，比如MD5，那么破解就不会比一个盐和一个散列更难破解（实际上它实际上更弱，因为散列是一个有损函数）。如果你使用强大的散列函数，比如bcrypt，它已经足够好了。

请大家，请停止尝试实施自定义加密系统，除非您有加密背景。你将搞砸了。

Answer 3

你可能已经很明显了，但你实际上是让人们在该设置中使用两个不同的密码登录。

如果您想让人们选择使用加密方式发送密码，我不会将其与严格的客户端密切联系起来，只需强制使用HTTPS，就像Harley已经暗示的那样。

Answer 4

您可能需要查看HTTP Digest authentication。这是一个标准化的协议，在任何情况下都避免使用明文密码。