为什么 PASETO 比 JWT 更适合基于令牌的身份验证？

JWT 对比 PASETO

JWT 对比 PASETO

如今，基于令牌的身份验证在 Web 和移动应用程序的开发中越来越受欢迎。

令牌有很多不同的类型，但其中，JSON Web 令牌（或 JWT）是使用最广泛的令牌之一。

然而，在过去的几年里，我们也发现了一些与 JSON Web Token 相关的安全问题，这主要是由于其标准设计不佳造成的。

因此，最近人们开始迁移到其他类型的代币，例如 PASETO，它有望为应用程序带来更好的安全性。

在本讲中，我们将学习有关 JWT 安全问题的全部内容，以及 PASETO 如何设计来解决所有这些问题。

以下是：

• YouTube 上的完整剧集播放列表链接
• 以及它的GitHub 仓库

基于令牌的身份验证

首先，我们来谈谈基于令牌的身份验证。

基本上，在这种身份验证机制中，客户端会发出第一个登录用户的请求，并在请求中向服务器提供用户名和密码。

服务器会检查用户名和密码是否正确。如果正确，服务器会使用其私钥创建并签署一个令牌，然后将200 OK包含已签名访问令牌的响应发送给客户端。

之所以称之为访问令牌，是因为客户端稍后将使用此令牌来访问服务器上的其他资源。

例如，假设客户端想要获取已登录用户的银行账户列表。那么它会GET /accounts向服务器发出请求，并在请求头中嵌入用户的访问令牌。

服务器收到此请求后，将验证所提供的令牌是否有效。如果有效，则请求将被授权，并将200 OK包含用户银行账户列表的响应发送回客户端。

请注意，访问令牌通常有一定的有效期，过期后客户端可以使用同一个令牌向服务器发送多个请求。

这就是基于令牌的身份验证的工作原理。

JSON Web Token

现在我们来聊聊JSON Web Token！以下是一个JSON Web Token的示例：

这是一个 base64 编码的字符串，由 3 个主要部分组成，以点号分隔。

第一部分（红色部分）是令牌的头部。解码这部分后，我们将得到一个 JSON 对象，其中包含令牌类型JWT和用于签署令牌的算法：HS256在本例中为 。

令牌的第二部分（紫色部分）是有效载荷数据。这部分用于存储已登录用户的信息，例如用户名，以及此令牌的过期时间戳。

您可以自定义此 JSON 有效负载以存储任何其他所需信息。在本例中，我们还添加了一个 ID 字段来唯一标识令牌。如果令牌泄露，我们需要撤销其访问权限时，此字段将非常有用。

请注意，JWT 中存储的所有数据仅经过 Base64 编码，并未加密。因此，您无需服务器的私钥即可解码其内容。

这也意味着我们可以在不使用密钥的情况下轻松地对头部和有效载荷数据进行编码。那么服务器如何验证访问令牌的真实性呢？

这就是令牌第三部分的作用：数字签名（蓝色部分）。如果您不了解数字签名算法的工作原理，我建议您在继续阅读之前先阅读我关于 SSL/TLS 的文章。

原理很简单，只有服务器拥有用于签署令牌的私钥。因此，如果黑客试图在没有正确密钥的情况下创建伪造令牌，服务器会在验证过程中轻松检测到。

JWT 标准提供了许多不同类型的数字签名算法，但它们可以分为 2 个主要类别。

对称密钥算法

第一种是对称密钥算法，其中使用同一个密钥对令牌进行签名和验证。

由于只有一个密钥，因此必须保密。所以这种算法仅适用于本地使用，或者换句话说，适用于可以共享密钥的内部服务。

属于对称密钥类别的一些特定算法有：HS256，，HS384和HS512。

这里是和 的HS256组合。代表基于哈希的消息认证码，是安全哈希算法。是输出位数。HMACSHA-256HMACSHA256/384/512

对称密钥算法非常高效，适用于大多数应用场景。

但是，如果有外部第三方服务想要验证令牌，我们就不能使用它，因为这意味着我们必须把我们的私钥给他们。

在这种情况下，我们必须使用第二类算法：非对称密钥算法。

非对称密钥算法

在这种算法中，使用的是一对密钥，而不是单个密钥。

私钥用于签署令牌，而公钥仅用于验证令牌。

因此，我们可以轻松地与任何外部第三方服务共享我们的公钥，而无需担心泄露我们的私钥。

在非对称密钥类别中，有几组算法，例如RS组、PS组或ES组。

这里，RS256基本上是具有和的RSA算法。PKCSv1.5SHA256

PS256它也是RSA一种算法，但采用了概率签名方案SHA256。它的设计目的是为了比现有算法更安全。PKCSv1.5

最后一个ES256就是椭圆曲线数字签名算法SHA256。

JWT的问题

好的，目前看来 JWT 似乎是一个不错的标准，它给了我们很大的灵活性，可以自由选择任何我们想要的签名算法。那么它究竟存在哪些问题呢？

弱算法

首先，JWT 存在签名算法薄弱的问题。它为开发者提供了过多的算法选择，其中也包括一些已知存在漏洞的算法，例如：

• RSA容易PKCSv1.5受到填充预言机攻击。
• 或者ECDSA可能面临无效曲线攻击。

对于缺乏安全方面丰富经验的开发人员来说，他们很难知道哪种算法最好用。

因此，JWT 赋予开发者过多的算法选择自由，就好比给了他们一把枪，让他们自己搬起石头砸自己的脚。

微不足道的伪造

但这还不是最糟糕的。JSON Web Token使得令牌伪造变得如此简单，以至于如果你在实现过程中不够谨慎，或者为你的项目选择了一个实现不佳的库，你的系统很容易成为一个易受攻击的目标。

JWT 的一个缺点是它将签名算法包含在令牌头中。

正因如此，我们过去也看到过，攻击者只需设置alg标头即可none绕过签名验证过程。

当然，许多库已经发现并修复了这个问题，但在为你的项目选择社区开发的库时，你应该仔细检查一下。

另一种更危险的潜在攻击是故意将算法标头设置为对称密钥标头，例如HS256明知服务器实际上使用非对称密钥算法来RSA签名和验证令牌。

让我来解释一下！

基本上，服务器的 RSA 公钥是公开的，因为它是一个公钥。

因此，黑客可以创建一个管理员用户的虚假令牌，并故意将算法标头设置为HS256对称密钥算法。

然后，他只需使用服务器的公钥对该令牌进行签名，并使用该令牌访问服务器上的资源。

请记住，服务器通常使用某种RSA算法（例如RS256用于签名和验证令牌的算法）来签名和验证令牌，因此它将使用RSA公钥作为密钥来验证令牌签名。

但是，由于令牌的算法标头表明HS256，服务器将使用此对称算法HS256而不是验证签名RSA。

由于黑客使用相同的密钥对令牌有效载荷进行签名，因此签名验证过程将成功，黑客的请求将被授权。

这种攻击非常简单，但威力却非常强大且危险，而且过去确实发生过，因为开发人员在验证令牌签名之前没有检查算法标头。

因此，为了防止这种攻击，至关重要的是，您的服务器代码中必须检查令牌的算法标头，以确保它与您的服务器用于签名和验证令牌的算法标头相匹配。

好了，现在你应该明白为什么JSON Web Token不是一个设计完善的标准了。它会带来很多潜在威胁。

因此，许多人都在尽量避免使用它，转而使用更稳定的产品。

PASETO - 平台无关的安全令牌

PASETO，即平台无关安全令牌，是最成功的设计之一，已被社区广泛接受为 JWT 最安全的替代方案。

强大的算法

它首先提供开箱即用的强大签名算法，从而解决了 JSON Web Token 的所有问题。

开发者不再需要选择算法，只需选择PASETO他们想要使用的版本即可。

每个PASETO版本都已集成 1 个强密码套件。并且在任何时候，最多只会PASETO激活最新的 2 个版本。

目前，有两个活跃PASETO版本，分别是版本 1 和版本 2。

PASETO 版本 1

版本 1 较旧，仅应用于无法使用现代加密技术的旧系统。

与 类似JWT，PASETO也有 2 个算法类别，分别对应 2 个主要用例。

对于本地或内部服务，我们使用对称密钥算法。

但与仅对有效载荷进行 Base64 编码并对令牌进行签名的 JWT 不同，它PASETO实际上使用强大的认证关联数据加密 (AEAD) 算法，通过密钥对令牌中的所有数据进行加密和认证AEAD。如果您不了解 AEAD，可以观看我关于 SSL/TLS 的视频。

版本 1AEAD中使用的算法是。PASETOAES256 CTRHMAC SHA384

对于公共场景，当有外部服务需要验证令牌时，我们必须使用非对称密钥算法。

在这种情况下，PASETO它采用与相同的方法JWT，这意味着它不会加密令牌数据，而只是对其进行 base64 编码，并使用私钥对内容进行数字签名。

PASETO版本 1中选择的非对称密钥算法RSA PSS是SHA384。

PASETO 版本 2

最新版本PASETO（版本 2）采用了两种更安全、更现代的算法。

对于本地对称密钥场景，它使用XChacha20算法Poly1305。

25519对于公钥非对称密钥场景，采用带曲线的 Edward 曲线数字签名算法。

这个选择让我想起了TLS 1.3它的设计初衷，即提高旧版本的安全性TLS 1.2，同时简化和减少 TLS 密码套件的数量。

非同寻常的伪造

现在有了 PASETO 的设计，代币伪造不再是件容易的事了。

因为算法标头已不存在，所以攻击者无法将其设置为 true none，也无法强制服务器使用其在此标头中选择的算法。

令牌中的所有内容也都经过身份验证AEAD，因此不可能篡改它。

此外，如果您使用本地对称密钥算法，则有效载荷现在是加密的，而不仅仅是编码的，因此黑客在不知道服务器的密钥的情况下不可能读取或更改存储在令牌中的数据。

听起来很棒，对吧？

在下一节课中，我将向你们展示如何使用 Golang 实现这两项JWT功能PASETO。

你会发现，PASETO与以往相比，它不仅更安全，而且更容易实施，也更简单得多JWT。

现在，让我们来看一下PASETO代币的结构。

这是PASETO用于本地使用的第二版令牌。该令牌由四个主要部分组成，各部分之间用点号分隔。

第一部分是PASETO版本（红色部分），即version 2：

第二部分是令牌的用途，它是用于local哪种public场景？在本例中，它是local用于哪种场景，这意味着使用对称密钥认证的加密算法。

第三部分（绿色部分）是令牌的主要内容或有效载荷数据。请注意，它是加密的，因此如果我们使用密钥对其进行解密，我们将得到 3 个较小的部分：

• 首先是有效载荷主体。在本例中，我们只存储一条简单的消息和令牌的过期时间。
• 其次，加密和消息认证过程中都使用的 nonce 值。
• 最后是消息认证标签，用于验证加密消息及其关联的未加密数据。

在这种情况下，未加密的数据是令牌的版本、用途和页脚（紫色）。

你可以在页脚中存储任何公开信息，因为它不会像有效载荷主体那样加密，而只是base64经过编码。因此，任何拥有令牌的人都可以对其进行解码，从而读取页脚数据。

在这种情况下，发明者是 Paragon Initiative Enterprises 公司PASETO。

请注意，页脚是可选的，因此您可以拥有一个没有页脚的 PASETO 令牌。例如，以下是另一个用于公共用途的 PASETO 令牌：

它只有 3 个部分，没有页脚。第一部分是PASETO版本号，即version 2。

第二部分是它的用途：public在这种情况下，这意味着使用非对称密钥数字签名算法对令牌进行签名，其有效载荷数据不会被加密，而只会base64进行编码。

正如您在这里看到的，有效载荷的绿色部分实际上是编码后的主体，我们可以轻松地对其进行解码以获得此 JSON 对象。

有效载荷中的蓝色部分是令牌的签名，由数字签名算法使用私钥创建。

服务器将使用其配对的公钥来验证此签名的真实性。

今天的基于令牌的身份验证讲座就到此结束了。

JSON Web Token我们已经了解到过去导致许多安全问题的设计缺陷，以及PASETO发明它是为了解决所有这些问题，从而使我们的开发人员的工作轻松得多。

希望您喜欢这篇文章，我们下篇文章再见，下一篇文章我们将用 Golang 编写代码来创建和验证令牌JWT。PASETO

如果您喜欢这篇文章，请订阅我们的YouTube 频道，并在Twitter或Facebook上关注我们，以便将来获取更多教程。

如果你想加入我在Voodoo的优秀团队，请点击此处查看我们的招聘信息。可远程办公，也可在巴黎/阿姆斯特丹/伦敦/柏林/巴塞罗那现场办公，公司提供签证担保。