1

我知道您可能在想“不要存储用户的凭据，用盐+胡椒对它们进行哈希处理，你这个白痴！ ”，但请继续阅读。

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

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

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

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

你怎么看？你会怎么办？

4

1 回答 1

2

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

  • 凭据对客户端无用
  • 在每个请求（以任何形式）时通过网络发送他的凭据不是一个好主意

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

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

于 2012-09-20T09:43:17.650 回答