security - session 与基于 token 的身份验证

Question

我想知道哪个更安全地进行身份验证，为什么？
基于 session 的身份验证或基于 token 的身份验证？

我知道 session 也可以用于其他事情，但现在我只对身份验证感兴趣。

如果使用 token (甚至不在内存中)，服务器端是否不会存储任何内容？如果是，那么它如何识别过期的 token ，因为它也是使用相同的 secret 签名的？

Answer 1

上面评论中链接的有关信息安全的问题有很多相关信息。话虽如此，在这个问题中提出的一些其他问题应该得到解决:
安全
对服务器实现一无所知，这两种方法都可以同样安全。基于 session 的身份验证主要依赖于 session 标识符的可猜测性(如信息安全答案中所述，它本身就是一个非常简单的 token )。如果 session 标识符是一个单调递增的数字 id，那么它就不是很安全，OTOH 它可能是一个具有巨大 key 空间的不透明加密强唯一 ID，使其非常安全。您可能会使用您选择的服务器框架提供的 session 实现，因此您需要检查一下。之后，使用 session 身份验证，您的服务器实现需要验证服务器存储的 session 是否包含相关授权(即用户帐户数据、角色等)——因为许多服务器 session 框架将默认根据需要自动生成空 session ，不能将 session 存在的事实作为有效认证和授权的足够证据。
例如，PHP 的内部 session ID 生成使用完全随机的 288 位数字(默认设置)，因此它被认为是安全的，OTOH - 默认情况下它会自动生成 session ，因此必须遵守先前的注释(或禁用自动 session 创建和使确保服务器仅根据需要创建 session )。
此外，如果 session ID 是使用 HTTP URL 查询字符串传递的，这是过去几天的默认设置，那么 session 很容易被盗，这会使整个过程变得不安全。
token 安全主要基于安全 token 生成:如果服务器以安全方式生成 token - 即不可猜测和可验证 - 如信息安全答案中所示。一个幼稚的实现(我见过一次)可能是对一个已知 token (例如用户名)进行 MD5 散列，这使得它非常不安全，即使是在加盐时也是如此。使用加密 token 时，安全性与加密强度密切相关，加密强度由所使用的算法、 key 长度以及 - 最重要的 - 服务器 key 的安全程度决定:如果服务器 key 被硬编码到服务器实现，然后该代码是开源的...
贮存
服务器是否需要存储任何东西通常取决于 token 的实现。
许多实现使用“API key ”的概念作为“ token 身份验证”，因此 token 通常只是一些加密安全的 ID，用于记录已生成哪些“API key ”的数据库。这需要存储，但具有实现更简单的优点，更重要的是能够撤销 token 。
另一种方法是让 token 携带自己的真实性——这允许服务器从本质上将 token 的存储卸载到客户端并将客户端用作数据库——非常像 HTTP Cookies 允许服务器将一些存储要求卸载到客户端的方式。客户端(通常用于客户端的特定设置，例如用户想要浅色界面还是深色界面)。
用于此的两种模式在信息安全答案中得到了很好的展示:签名和加密。

签名: token 是身份验证器凭据(例如用户名)的一些简单编码(如 JSON 或 CSV)，可能还有 token 的到期时间(如果您想让 token 过期 - 通常是个好主意，如果您无法撤销) token )，然后服务器使用服务器 key 对生成的文本进行签名，并将其添加到 token 中。当客户端提交 token 时，服务器可以从 token 中提取明文，重新签名并将新签名与提交的 token 中的签名部分进行比较 - 如果它们相同，则 token 有效。验证后，您可能希望根据当前时间检查验证的到期日期。这里的主要缺点是应注意明文身份验证详细信息不足以让攻击者重新进行身份验证 - 否则会损害安全要求。即不要将密码作为 token 的一部分或任何其他内部细节发送。

加密: token 是通过再次编码所有相关的身份验证细节，然后使用服务器 secret 加密明文并仅提交加密结果来生成的。如果可以信任加密方案，则身份验证详细信息可以包括内部数据 - 但应注意，因为攻击者可以离线使用大型加密文本比小型签名具有更大的攻击面，并且弱加密算法的弹性会降低在这种用法中，而不仅仅是签名。

在这两种方法中，安全性与加密/签名算法的强度密切相关——弱算法将允许攻击者对服务器 secret 进行逆向工程并生成新的有效 token 而无需身份验证。
个人笔记
在我看来，基于加密 token 的身份验证往往不如基于 session 的身份验证安全，因为它依赖于(通常是单一的)开发人员从设计到实现再到部署正确地做所有事情，而基于 session 的身份验证可以利用现有的实现来做大多数繁重的工作，在这里很容易找到高质量、安全且大量使用和测试的 session 存储实现。在推荐使用加密 token 之前，我需要一个非常令人信服的理由来说明为什么不需要 session 存储。
永远记住加密安全的第一条规则:永远不要设计自己的一次性加密措施。