在会话中存储用户凭证的安全方式答案

【问题标题】：Secure way of storing user's credential in a session在会话中存储用户凭证的安全方式
【发布时间】：2012-09-20 09:22:53
【问题描述】：

我知道您可能在想“不要存储用户的凭据，用 salt+pepper 对它们进行散列，你这个白痴！”，但请继续阅读。

我正在开展一个项目，该项目将向用户询问其数据库的凭据（登录名/密码）。这些凭据将针对数据库进行尝试，如果连接成功，我将“保留”它们以按照用户的要求对数据库进行一些工作（创建表、更改行、执行 SELECT 等）。

这意味着，每次用户执行某项操作时，我都会在执行他的请求之前重新连接到数据库 => 我无法对凭据进行哈希处理，因为它们对后续请求毫无用处。如果你愿意，它就像 phpMyAdmin。

所以我想出了各种可能，但每个都有缺陷。我正在寻找建议以确定哪个更好。

只需使用明确的登录名/密码的会话 cookie。但只允许通过 HTTPS 使用：这是最简单的实现方式。我看到的唯一缺点是，如果客户端存在 XSS，则可以检索凭据。
相同的会话 cookie，但使用 AES 加密的登录名/密码。我相信这就是 PhpMyAdmin 所使用的。我也可以通过只允许 HTTPS 走得更远。
将凭证以明文形式存储在本地会话存储中（sqlite 中的 session.db），并为将使用给定令牌 + 浏览器详细信息检索的客户端使用令牌。缺点：如果攻击者访问 session.db 文件，他将能够读取尚未从文件中删除的会话。我不认为加密它们会有用，因为如果他可以访问 session.db，他当然也可以访问用于加密它们的 SECRET_KEY。

你怎么看？你会怎么做？

【问题讨论】：

【解决方案1】：

我建议不要使用 1. 或 2.，原因如下：

所以留下来的是版本 3 的变体。将其存储在会话中。这有一个重要属性：如果您的会话存储不安全，这意味着您的服务器不安全。游戏结束。

不过，为了防止对 session.db 的攻击，您可以在您的应用程序中使用硬编码的密钥库。这个密钥库用会话令牌加盐，然后散列，结果用作加密和解密客户端凭据的密钥。这样，攻击者将需要破坏 session.db 和您的应用程序（以获取密钥库）。如果他能做到这一点，没有什么可以帮助你。

【讨论】：

啊，很好，这意味着关键基础是胡椒，令牌是盐。此外，这意味着如果攻击者访问 session.db 和密钥库，他还需要令牌来解密凭据：IMPOSSIBRU：D
对不起，并非不可能：Token 必须在 session.db 中才能查找对应记录！即使您还使用密钥库对其进行调味，如果攻击者获得了密钥库，游戏就结束了。 如果攻击者可以破解您的应用，他通常可以获得您的应用可以看到的所有数据。这很可悲，但仍然是事实。
是的，你是对的。但是，它仍然比为每个请求发送凭据要好。我要和这个一起去！谢谢:)
不会只使用另一个带有令牌帮助的cookie而不是使用会话令牌吗？然后将无法检索凭据，因为令牌不会存储在 session.db 中。