当通过https连接时，在Cookie中存储用户密码有什么风险？

Question

A Note

我非常了解会话和安全的基于Web的身份验证等理论，所以请不要从基础知识开始，或者给出含糊不清的答案。我不是在寻找最佳实践，因为我知道它们。我正在寻找他们背后的真正风险，使最佳实践成为现实。

我已经阅读并同意这些原则，即在任何给定时间都应该在Cookie中存储会话标识符。

故事

但是......我继承了一个生锈的旧应用程序，该应用程序在Cookie中存储用户名，密码和附加ID，在整个站点中将其作为验证/授权进行检查。

此网站始终（只能）通过HTTPS访问，并且根据您的立场，是一个“低风险”网站。

应用程序在当前状态下不能以处理Sessions的方式重写 - 正确实现这样的事情本质上需要重写整个应用程序。

问题

当向权力提出建议时，在Cookie中以明文形式存储用户的ID /密码是一个非常糟糕的主意，考虑到连接是什么真正的风险总是通过HTTPS启动和操作？

例如：是通过物理访问包含Cookie的机器来破坏此信息的唯一明显方法吗？还存在哪些其他真正的风险？

Answer 1

HTTPS只是通过加密通过网络传输的数据来防止中间人攻击。信息仍然是客户端的纯文本。因此，客户端计算机上的任何内容都可以通过该cookie信息并提取相关信息。

Answer 2

其他一些风险包括cross-site scripting attacks可以实现cookie盗窃，以及谁知道哪种浏览器漏洞可以实现cookie盗窃。

Answer 3

给定浏览器的“cookie jar”可能无法安全存储，即攻击者可能无法通过LAN物理访问机器或从分布式文件系统（例如，如果机器存储用户）读取它存储服务器上的家庭，允许漫游），或通过计算机上运行的应用程序。

Answer 4

某些浏览器会将Cookie保存在可以在计算机上显示的文件中。 IE6浮现在脑海中。 在我看来，cookie并不仅限于一个网站。大量广告在多个网站上使用Cookie。如果我去NextTag然后找一台尼康D700相机 我在slashdot.org上看到了NextTag的广告。这是跨站点cookie的示例。大多数用户在整个网络上使用相同的密码，因此如果您将密码存储到一个网站并使其更容易获得，那么恶意人员迟早会到达它。

总结一下，这将是一个非常非常糟糕的主意。在我工作的网站上，我们根本不保存用户密码。我们将它们转换为哈希键并保存哈希键。这样我们就可以验证用户，但如果我们放弃了内容，那么密码就不会泄露。这是在服务器端，而不是浏览器端！

Answer 5

这里的人们已经提到过“中间人”攻击。问题是，即使使用https，它仍然是可能的。有不同的方法可以做到这一点 - 其中一些方法可以在物理上访问网络时进行中继，而其中一些方法则没有。

这里的底线是即使使用https，某人仍然可以在您的应用和浏览器之间插入自己。一切都将通过，并将从浏览器看起来与服务器证书完全相同。入侵者必须发送自己的而不是真实的。

浏览器会检测到证书存在问题 - 通常会发出不同的DNS名称，或者更有可能无法验证。

以下是问题：如何向最终用户呈现此违规行为以及最终用户将如何做出反应。在IE的旧版本中，问题的所有迹象都是状态栏右侧的一个小破锁图标 - 许多人甚至都不会注意到这一点。

这引入的风险取决于环境是什么以及用户是谁（如何训练）

Answer 6

大多数Cookie都是有限的时间凭据。例如，会话标识符在几个小时后过期或在浏览器窗口时被遗忘。即使攻击者获得对会话cookie的访问权限，也可以保证他们不会继续访问该帐户，也无法阻止原始帐户持有者登录。防止长期帐户泄露是用户被要求提供旧密码的原因之一在被允许进入新的之前。

如果披露了包含用户名和密码的cookie，则其寿命会更长。此外，许多用户在网站之间共享密码。正如其他人所指出的那样，cookie可以通过跨站点脚本轻松披露。

最后，cookie是否标有“安全”标志？如果不是这样，即使使用HTTPS来服务整个站点，主动网络攻击也很容易迫使浏览器泄露它。

Answer 7

两个主要漏洞是跨站点脚本攻击，有人访问用户的计算机。

您是否考虑过只在cookie中存储密码哈希而不是原始密码？它需要进行一些编码更改，但不会像更换整个身份验证系统那样多。