-1

我想将 cookie 的密钥与在数据库中找到的密钥进行比较，以便让回访者自动登录网站，这意味着 db 中的密钥和 cookie 将与特定用户相关联。

我的问题是什么更好，将密钥存储到存储用户名及其密码的表中，或者创建一个单独的表，当然会有用户名和相关的密钥和时间戳。

复杂性是这里的一个问题——此外，我试图找到一个 innodb 或 Isam 是否更适合上述情况。

更复杂的是，从现在开始很难预测应用程序将有多大，以及这将如何影响数据库的设计。我越早找到合理的解决方案越好

4

1 回答 1

2

我将用一些关于如何解决这个问题的想法和想法来回答这个问题。

现在，您在执行此操作时首先应该考虑的是其他站点如何执行此操作：

  • 亚马逊允许您在持久性 cookie 下浏览网站，但它们不允许在不强制重新登录的情况下下订单或更改详细信息。然而，话虽如此，这仍然存在严重的安全漏洞。如果您允许单击订购，然后其他人使用您的计算机并单击来自亚马逊的活动电子邮件中的链接（例如广告），则仍然有可能将订单放置在其他人的帐户上而无需实际上已登录（是的，我偶然发现了这一点，谢天谢地）。
  • Facebook 对亚马逊采取了类似的方法。从个人经验来看，我认为他们要求每两天重新登录一次以编辑帐户详细信息等。
  • 我可以收集到的 Stackoverflow 没有这样的安全措施。登录后，您将登录指定的持续时间。
  • 谷歌有一个 2 年以上的 cookie，每周一次左右要求您重新登录以验证自己。

因此，正如您所看到的，许多站点不仅允许持久登录来控制其用户交互，而且实际上返回的持久登录很少甚至完全登录一个人。相反，大多数网站实施的是 2 层登录系统，您可以在其中以 cookie 用户的身份查看该网站，但是您无法编辑任何内容而无需再次登录。

你会立即注意到这里的事情。这些网站中的许多网站只关心浏览器会话到期时的 cookie 到期。持久性 cookie 很少有短期到期，所以这一点是无用的。正如@pyruva 所说，窃取某人的 cookie 并以他们的身份查看网站很容易，这种情况一直在 Facebook 上发生（您甚至可以找到有关如何操作的视频教程）。

所以首先要记住的是，持久登录本质上是不安全的。通过实现诸如 2 层身份验证系统之类的东西，使其安全的方法通常在您的应用程序逻辑中。

您永远不应该做的一件事是将有关用户的一些个人身份信息存储在该 cookie 中，例如用户名或密码，即使是散列形式。一个更好的方法是使用随机生成的令牌（这里考虑 OAuth2）最初与服务器握手。

当然，您需要考虑的另一件事是总体上保护您的 cookie。你可以在谷歌上找到很多关于这个的资源，但是这里有一个链接应该很有帮助：http: //www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html

所以希望这能给你一些关于如何解决这个问题的方向和提示。

编辑

当涉及到 cookie 时，访问您网站的每个用户实际上都有两个会话。他们有一个浏览器会话，当浏览器关闭时，将从他们的浏览器中删除 cookie（通常在 HTTP 标头中表示为 0 过期时间）。

然后是持久会话。您现在要实施的一个，cookie 可以在它们实际过期之前持续数年。

这就是我所说的浏览器过期。因此，大多数网站都包含临时 cookie，一旦您关闭浏览器，这些 cookie 就会被删除。这些 cookie 通常用于保持您的会话。

如果网站关心 cookie 过期，那么他们不会在您的计算机上保存有效期为 2 年的 cookie。如果有人要使用过期的 cookie 来滥用您的帐户，让我们面对现实吧，他们有点不走运，因为 cookie 仍然完全有效。这是一个更大的安全威胁，但它确实证明了我的观点。

于 2012-09-27T14:28:41.810 回答