1

基本上，我想要的是使用登录 cookie 的替代方案，因为它们在技术上可以被猜到（有办法解决这个问题，但为什么不完全消除威胁）？

我在想的是一个系统，它有一个大的不要在公共计算机上使用警告，它允许用户不使用 cookie 自动登录，而是通过遵循/login/email@example.com/myPassword 之类的 URL 来自动登录。

我想问的是，我应该费心创建这样的系统还是会产生更多的安全漏洞？一方面，基于 cookie 的人可以简单地再次请求密码，例如，如果 IP 或用户代理不匹配，另一方面，我可以通过不必存储 cookie 名称来节省相当多的数据库空间.

4

2 回答 2

4

使用您的方法，用户的密码现在被公开：在他们的浏览器历史记录中，在您的服务器日志中，在任何网络嗅探工具中，等等。用户的密码不应出现在 URL 中。所以不，这不是一个好主意。

于 2012-06-26T08:28:38.200 回答
2

我同意 Simeon 的观点，但只想指出一些额外的事情：

  • Cookie可以被劫持，你是对的，但是 SSL 之类的东西在合理的范围内可以很好地防止这种情况发生。
  • 如果您使用 SSL，两种方法（您的方法和 cookie）都会被窃听者隐藏。
  • 正如 Simeon 指出的那样，所请求的 URL 恰好存储在比 cookie 更多的地方，这使得意外妥协或故意妥协的可能性更大。
  • 然而，更重要的是，cookie 只是随机生成的字符串，特定于您的站点和您的站点，而纯文本密码更有价值。您网站的明文密码可能与数百个其他网站使用的密码相同。换句话说，被泄露的 cookie 对一个站点的影响最大。另一方面，泄露的密码可能会产生更广泛的影响。
  • 因为您注意到猜测，PHP 会话 ID 比典型的密码长得多。PHP 通常会生成 27 到 40 个字符之间的会话 ID，是平均密码大小的 4 倍以上。此外，密码通常可以通过（修改的）字典攻击之类的方法找到，所需时间只是对整个搜索空间进行暴力搜索所需时间的一小部分。换句话说，猜测明文密码比猜测 cookie 的内容要容易得多，如果您担心 cookie 的安全性，请增加长度并包含服务器端逻辑以仅接受来自同一 /24 中的客户端的 cookie地址空间。如果您仍然担心，请强制用户更频繁地重新进行身份验证。
于 2012-06-26T08:44:22.933 回答