会话与基于令牌的身份验证

Question

我想知道实现身份验证哪个更安全？为什么？基于会话的认证或基于令牌的认证

我知道会话也可以用于其他事情但是现在我只对身份验证感兴趣.

如果使用令牌(甚至在内存中),是否真的没有任何东西存储在服务器端？如果是,那么它如何识别过期的令牌,因为它也是使用相同的秘密签署的？

Answer 1

上面评论中链接的有关信息安全的问题有很多相关信息。话虽如此，在这个问题中提出的一些其他问题应该得到解决：

安全

对服务器实现一无所知，这两种方法都可以同样安全。基于会话的身份验证主要依赖于会话标识符的可猜测性（如信息安全答案中所述，它本身就是一个非常简单的令牌）。如果会话标识符是一个单调递增的数字 id，那么它就不是很安全，OTOH 它可能是一个具有巨大密钥空间的不透明加密强唯一 ID，使其非常安全。您可能会使用您选择的服务器框架提供的会话实现，因此您需要检查一下。之后，使用会话身份验证，您的服务器实现需要验证服务器存储的会话是否包含相关授权（即用户帐户数据、角色、

例如，PHP 的内部会话 ID 生成使用完全随机的 288 位数字（默认设置），因此被认为是安全的，OTOH - 默认情况下，它会自动生成会话，因此必须遵守之前的注释（或禁用自动会话创建和使确保服务器仅根据需要创建会话）。

此外，如果会话 ID 是使用 HTTP URL 查询字符串传递的，这是过去几天的默认设置，那么会话很容易被盗，这会使整个过程变得不安全。

令牌安全主要基于安全令牌生成：如果服务器以安全方式生成令牌 - 即不可猜测和可验证 - 如信息安全答案中所示。一个幼稚的实现（我见过一次）可能是对已知令牌（例如用户名）进行 MD5 散列，这使得它非常不安全，即使是在加盐时也是如此。使用加密令牌时，安全性与加密强度密切相关，加密强度由所使用的算法、密钥长度以及——最重要的——服务器密钥的安全程度决定：如果服务器密钥被硬编码到服务器实现，然后该代码是开源的...

贮存

服务器是否需要存储任何东西通常取决于令牌的实现。

许多实现使用“API 密钥”的概念作为“令牌身份验证”，因此令牌通常只是一些加密安全的 ID，用于记录已生成哪些“API 密钥”的数据库。这需要存储，但具有实现更简单的优点，更重要的是能够撤销令牌。

另一种方法是让令牌携带自己的真实性——这允许服务器本质上将令牌的存储卸载到客户端并将客户端用作数据库——非常像 HTTP Cookies 允许服务器将一些存储要求卸载到客户端的方式。客户端（通常用于客户端的特定设置，例如用户想要浅色界面还是深色界面）。

用于此的两种模式在信息安全答案中得到了很好的展示：签名和加密。

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

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

在这两种方法中，安全性都与加密/签名算法的强度密切相关——弱算法将允许攻击者对服务器秘密进行逆向工程并生成新的有效令牌而无需身份验证。

个人笔记

在我看来，基于加密令牌的身份验证往往不如基于会话的身份验证安全，因为它依赖于（通常是单一的）开发人员从设计到实现再到部署正确地做所有事情，而基于会话的身份验证可以利用现有的实现来做大多数繁重的工作，在这里很容易找到高质量、安全且大量使用和测试的会话存储实现。在推荐使用加密令牌之前，我需要一个非常令人信服的理由来说明为什么不需要会话存储。

永远记住加密安全的第一条规则：永远不要设计自己的一次性加密措施。