您需要保护 GUID 传输（考虑服务器冒充另一台服务器或中间人的可能性）；我强烈怀疑这会迅速演变为需要非对称加密的东西，最后是 HTTPS 的精简版本。由于完整的 HTTPS 已经可用，这似乎是重复劳动。

另一方面，使用 GUID（当一切都说了又做了，作为 [临时] 共享密钥）将无法防御客户端受到损害（恶意软件、“黑色”取证，甚至可能是社会工程，具体取决于如何界面设计）。为此，您需要一个本地受信任的托管系统 - 一种安全的智能卡，这样您就无法读取和复制内部的实际内容，同时能够向第三方（服务器）证明数据存在。

但到那时，我们真的需要cookie吗？我们将拥有一张安全保存用户登录数据的智能卡；然后将会话链接到浏览器而不是用户名会简单得多。“记住我”功能将由您插入智能卡来执行。

另一种更简单的可能性是，正如用户 lesto 所建议的，将私人同意的秘密存储在密码保护区域 - “密钥环”、“投资组合”或“钱包” - 就像表单密码一样。用户使用主密码解锁密钥环，然后浏览器可以进行身份​​验证。

但是整个方案可以通过强制安全 cookie 与缓存密码一起存储在安全区域中以更直接的方式实现。在通过安全连接接收到 cookie 时，浏览器会请求用户解锁安全区域，为已存在的同一个域找到具有相同名称的 cookie，然后重复请求，这次发送预期的 cookie。从用户的角度来看，他进入了一个启用了“记住我”选项的安全站点，出现了一个浏览器弹出窗口，要求输入主密码，接下来他知道他已经登录了。

攻击者将无法（weeeellll...）访问 HTTPS 交换，如果他要夺取计算机，他会在缺少主访问密钥的 AES-256 加密块中找到 cookie 和密码。

您所建议的内容具有不同的隐私和安全含义，并且一般不会起作用，因为您无法保证您提到的 GUID 的真实性：

1. 它可以轻松捕获，您只需将用户重定向到您有权访问的任何网络服务器。
2. 没有什么可以阻止某人编写自定义浏览器（或修改现有浏览器的源代码）来伪造 GUID，因此您的观点“不应被修改（在任何情况下）”不会真正起作用。
3. 此解决方案还有其他各种隐私影响，例如能够唯一地跟踪某人（如果您不查看前面的几点）。

这难道不能完全解决会话劫持/cookie 劫持的问题，因为来自一个浏览器的 cookie 对另一个浏览器完全没用？

不完全的。如果有人在同一台计算机上劫持了您的 cookie 怎么办？（公用电脑）。并且，谁发送 GUID？浏览器本身，因此它留下了一个很大的漏洞，因为您也可以复制 GUID。永远不要相信用户输入！

我建议你看看 HttpOnly ：https://www.owasp.org/index.php/HttpOnly

使用在第一次浏览器启动时生成/由用户（或者可能基于域）提供的私钥更改“GUID”，以及一种签名和识别客户端响应的方式。

这正是基于安全外壳 (SSH) 的自动身份验证的工作原理。但要实现真实，您必须编辑浏览器以使用固定或基于域的私钥，您添加一个登录页面，成功登录将上传客户端的公钥并且必须存储它，并修改 HTTPS 服务器以检查客户身份与存储的身份相对应。

请注意，这与实际的 HTTPS 非常相似，您“只需”添加持久客户端密钥和服务器端密钥<->会话查找。

这实际上称为“客户端认证的 TLS 握手”，但通过经典登录进行的密钥交换不符合标准。

然后，只要私钥受到保护，您的会话就会受到保护，但是因为已经有很多浏览器提供了一种在其中存储密码的方法，所以这不应该被视为一个大问题