【问题标题】:Encrypting password over https that was initally not encrypted - pros and cons通过最初未加密的 https 加密密码 - 优点和缺点
【发布时间】:2015-06-23 17:14:48
【问题描述】:

我有一个流行的应用程序,我继承了该应用程序,用户凭据通过线路裸露到身份验证端点。现在我有一项任务来“散列”凭据以防止中间人攻击等,因为您现在 https 不久前就遭到了破坏,所以一切皆有可能,而且安全性更好。

现在,想象一下如果我是 md5(密码),那么由于这是我无法在身份验证端点解密的一种方式。这意味着所有当前用户都必须在那里重置密码,以便我可以再次对其进行哈希处理。

在这个问题上,处理用户密码一开始没有加密但现在应该加密的情况的最佳方法是什么?

【问题讨论】:

  • 散列绝对不会阻止中间人。如下所述,您需要修复 TLS。如果您的应用程序如您所说的那样受欢迎,我强烈建议要求每个人更改密码。您还应该阅读Salted Password Hashing,因为您误解了一些重要概念。

标签: security encryption https md5


【解决方案1】:

最好的方法是修复您的 TLS 设置。如果你不能信任你的 TLS 连接,你也不能真正信任浏览器中运行的任何东西。

由于您仍然将 MD5 与加密混淆,我强烈建议您不要创建自己的密码哈希协议。

【讨论】:

  • 您正确的 md5 不是加密,因为它是一种方式。它是一个哈希函数。我认为最好的方法就是在另一端加密和解密。感谢您的帮助。
  • 如果加密,使用非对称加密,发送公钥进行加密。这并不安全,因为攻击者仍可能将其替换为另一个公钥,但至少这是一种主动攻击,而不是攻击者只需查看传输中的字节的被动攻击。
  • 不同意“或者,您可以将当前的密码散列方法放在浏览器中,然后在服务器上添加额外级别的密码散列”——这很容易受到“传递散列”攻击。换句话说,绝对需要 TLS 来解决这个问题。见Method to Protect Password in Databases for Web Applications
  • 好的,这是有道理的...我将删除该选项。感谢 TheGreatContini 的警告。
猜你喜欢
  • 2011-06-17
  • 1970-01-01
  • 1970-01-01
  • 2019-09-09
  • 2020-05-01
  • 1970-01-01
  • 2010-10-23
  • 1970-01-01
  • 2019-07-23
相关资源
最近更新 更多