我正在用PHP创建一个登录系统，我想知道：为什么需要会话？登录系统：为什么需要会话？

如果我用userid存储一个cookie，并且sessionid不会带来与使用userid和密码hash（假设密码hash足够强）存储cookie完全相同的安全风险？是的，有人可能会窃取cookie，但如果他们窃取sessionid cookie，是不是一样？

有人能告诉我在每个（合理安全的）登录系统中使用会话的原因是什么？

2010-07-30 user406925

会话ID有避免在成功实体验证（成功登录）后重复使用用户的用户名和密码，而不是每次向您的服务发送的请求都要求用户输入用户名和密码，您只需要检查与他/她相关的session_id。（是的，你也可以通过使用他的用户名和密码来达到同样的效果）。在这种情况下，后一种方法存在更严重的安全风险。 – ultrajohn 2010-07-30 17:02:28

你是对的，在给定一个非常强大的散列的情况下，在cookie中公开密码的风险可能非常低。但为什么要麻烦？只需使用随机生成的会话ID，并且绝不可能将密码“取消”。除此之外，您应该尽可能重新使用现有的身份验证框架，因为它确实很复杂。例如，看一下https://github.com/delight-im/PHP-Auth，它既是框架不可知的，也是与数据库无关的。 – caw 2016-10-21 22:14:36

会话的好处之一是您可以在每次有人登录时甚至在用户访问期间定期生成新的会话。如果您只是使用userid和密码的一些散列，那么只要有人偷走了您的cookie，他们就可以无限期地登录。会话过期。

来源

2010-07-30 16:34:16 Nick

好点。但是，如果您点击“记住我”（因为大多数用户最终会这样做），那么风险会不会相同？ – user406925 2010-07-30 17:01:46

如果有人窃取了一个cookie，那么当真正的用户下次登录时，他的会话ID将不再起作用，因此他将被提示进行登录。一旦他用用户名/密码登录，骗子的sessionID将不再起作用。 – supercat 2010-07-30 17:04:14

'记住我'按钮通常意味着在浏览器关闭时将会话cookie设置为不过期（例如变为永久）。没有什么不可思议的。 – 2010-07-30 18:28:39

您可以设置为立即过期或从现在开始如果您想要过期的Cookie。浏览器关闭时会话立即过期。因为这一点，他们通常更安全。在这个特定的场景中，除了到期的长度以及事实上，一个存储在客户端机器上，而另一个存储在内存中，实际上并没有什么区别。

来源

2010-07-30 16:34:20 Kolten

Cookie和会话实际上没有可比性 - Cookie是实现会话的一种方式（另一种是在网站URL的查询字符串中）。如果你想要他们，会话可以从现在开始过期一年。 – Nick 2010-07-30 16:36:00

正如尼克提到的，会话可能需要更长的时间才能过期，并且cookie可以在浏览器关闭（甚至更早）时设置为过期，因此持续时间似乎不是一个有效的参数。 @Nick我不想比较两种实现会话的方式，我试图将基于cookie的会话与基于cookie的无会话身份验证进行比较。 – user406925 2010-07-30 16:56:43

由于99.9％的PHP会话实现依赖于cookie，因此基于cookie的会话系统和基于cookie的会话系统在涉及cookie信息（到期等）时会有完全相同的限制。区别不在于信息的存储位置（都将Cookie存储在客户端计算机上），它是存储敏感信息的地方（使用会话，位于服务器端，无会话位于客户端）... – ircmaxell 2010-07-30 17:01:36

因为是更安全的时期。

通过会话信息存储在服务器中，因此如果有人仍然存在任何类型的信息，那么还需要几个步骤。通过cookies，任何人都可以直接从本地机器获取信息，而无需服务器请求。

来源

2010-07-30 16:42:27 Pablo

这不一定如此，可以实现您自己的会话处理程序，可以存储使用Cookie加密的信息。 – 2010-07-30 16:54:40

指定的可解密数据？有趣的...但值得加密cookie中的数据吗？当你可以使用会话 – Pablo 2010-07-30 16:59:36

而不是创建一个哈希，为什么不加密会话ID，以便您可以解密它，看看它是否超时。

如果您还将它绑定到IP地址，那么您可以使其更安全。

或者，您可以让用户只需登录每个他们想要访问的页面。

一旦解决方案是有一个JavaScript应用程序，实际上获取用户的所有信息，所以，用户名/密码存储在JavaScript中。然后，对于每个页面请求或交互，传递用户名/密码或者一些初始身份验证结果的令牌，该令牌也如上所述加密。

然后你不需要一个会话，如果用户关闭该选项卡，他们的信息就消失了，所以没有安全风险。

Session id比javascript更简单，所以大多数人选择会话，但是，你不必这样做。

来源

2010-07-30 16:43:56

如果我用userid存储了一个cookie，并且sessionid不会带来与使用userid和密码hash（假设密码散列足够强大）存储cookie完全相同的安全风险？是的，有人可能会窃取cookie，但如果他们窃取sessionid cookie，是不是一样？

是的，这可能是一个类似的风险。窃取cookie可能会因为以下几个原因而被认为不严重：

会话cookie的寿命较短。
用户经常回收站点之间的用户名/密码，如果他们的凭据被截取，这可以暴露他们更多。
会话实际上可能不允许用户执行与用户名/密码相同的操作;例如，该网站可能要求用户在某个时间点重新输入他的凭证。
该网站可能会将会话有效期限制为一个特定的IP。

但是，有一个会话cookie被盗可能在某些情况下会像使用户名/密码被盗一样严重。为了对窃取的证书拥有坚实的安全性，您必须加密（https）用户和Web服务器之间的所有流量（甚至在他们进行身份验证之前），否则主动攻击者可能会更改表单提交的action，其中用户按顺序输入证书使其不能通过安全通道发布）。

来源

2010-07-30 16:47:03 Artefacto

我同意你说的大部分事情，但我认为使用'绝对安全'在安全环境中使用太强大了，只是一个念头！ :) – ultrajohn 2010-07-30 16:53:00

1.并不总是 2.所以，你基本上说哈希是不安全的（即使有盐等），我们不应该相信他们？ 3.＆4.好点。所以原因是会话更具可扩展性？ – user406925 2010-07-30 16:58:59

@ultra我重述了它。我将保留“无条件安全”一词，以便一次性使用：p – Artefacto 2010-07-30 16:59:32

您描述了一个设计，其中每个页面请求都验证了用户凭据，并且登录表单仅用于在浏览器中存储这些凭据。我看到几个问题与这些不寻常的做法：

您传递有关每 HTTP请求的敏感信息。
为了验证您可能必须运行数据库查询的凭据，并且一次又一次地执行该操作。
您必须验证凭据才能知道请求来自谁。
具有相同凭据的同时连接将共享数据[见附录]。

验证用户一次（可能使用加密通道或散列信息）并在指定时间记住它更为典型。

无论如何，会话和cookie都是完全不同的工具。 Cookies是客户端存储，而会话是服务器端。它们仅相互关联，因为最典型的会话实现使用cookie来存储会话ID（因为HTTP是一种无状态协议，您需要使用这种技巧来跟踪来自谁的请求）。服务器端存储的好处在于您可以完全控制它：

您可以根据需要使用尽可能多的空间。
您可以使用任何您需要的数据格式。
您可以保留敏感数据或您不希望用户看到或破坏的内容。
您可以信赖的信息自你把它放在那里。

附录

如果在基于会话分配随机ID经典会话启动系统的注册用户可以在不同的计算机（即使是在一台电脑多人同时会话实例或，例如，一个在Firefox还有三个Chrome隐身模式窗口）。如果你只用他的用户名识别访问者，那么用户只会有一个会话：如果他回家吃午饭，他会发现他在工作时离开的会话，如果他与朋友分享他的密码，他会看到他的朋友是什么这样做。这可以被认为是一个错误或一个功能，当然，有很多技巧来阻止它。只要考虑到它。

来源

2010-07-30 16:54:55

感谢您的广泛答复。 1.但它的加密:) 2.对于db存储的会话也是如此，许多系统都使用它。 3.您必须验证sessionid以查看请求来自哪里。点是？ 4.我不明白。你能详细说明一下吗？ – user406925 2010-07-30 17:13:46

@lucrezia：我在＃3中的意思是，你会自动知道具有相同会话ID的所有请求来自同一个人（注意我并不是说* user *），即使他还没有通过身份验证，检查是必需的（除非你想）。如果你只能通过他的用户凭证来识别一个人，那么你需要检查用户+通过匹配，然后才能找出它是同一个人。而且，当然，匿名浏览器无法从与会话相关的内容中受益。我会尽力详细说明＃4。 – 2010-07-30 21:16:43

登录系统：为什么需要会话？

回答

附录

相关问题