关于 JSON Web Token 安全性的几个问题？ [关闭]

Question

我一直在开发一个使用 Tomcat API 发送/接收数据、登录、注销等的 Android/IOS 应用程序。我的主要身份验证形式是使用 SHA-512 通过带有 HMAC 的 JSON Web 令牌。认证照常进行。用户提供他们的凭据（用户 ID 和密码）以进行首次登录。服务器验证凭据，如果它们是正确的，它会生成一个 JWT 并将其返回给用户，用户可以使用该 JWT 在未来的请求中对自己进行身份验证。该令牌包含一个自定义声明，该声明指定了用户 ID，用于了解哪个用户正在发出请求。我对 JWT 进行了一些研究，并且在许多问题上意见不一。我有几个问题希望您能阐明：

1- 使用 JWT 作为我的 API 的唯一身份验证机制是否足够？

2- 在安全性方面，使用 HMAC 的 JWT 和使用 RSA 的 JWT 有区别吗？

3- 理想情况下，我应该在哪里存储我用来签署我的令牌的对称签名密钥？目前，我将密钥直接传递给生成我的令牌的函数。这样做安全吗？

4- 我应该定期更改签名密钥以提高安全性吗？

5- 我是否可以信任我插入到令牌中以识别发出请求的用户的用户 ID 声明？

6- 令牌是否有“理想”的到期时间？有些人建议只需 15 分钟，而另一些人则说 3 小时就可以了。

7- 我应该担心限制特定用户可以拥有的令牌数量吗？一个用户可能有多个移动设备，并且在任何时候都可能有多个令牌。在这种情况下，只要用户有凭据，就没有什么能阻止用户从我的服务器获取数千个令牌。我是否应该实施某种机制（例如：数据库）来跟踪用户拥有的令牌？如果在验证/生成令牌时必须进行额外的数据库查询，这似乎违背了 JWT 的目的并增加了复杂性。

8- 我是否需要担心撤销令牌？一些人建议拥有到期时间短的令牌就足够了。其他人指出，如果您在用户退出应用程序后不撤销令牌，那么您永远无法拥有真正的退出机制。只是等待令牌过期是错误的吗？在安全性方面，我什么时候需要撤销令牌？

抱歉，帖子太长了。我一直在担心处理这些问题的最佳方法。我很感激任何帮助。谢谢

Answer 1

1- 使用 JWT 作为我的唯一身份验证机制是否足够？ API？

通常是的，只要“签名密钥”具有足够的强度（128 位，由 CSPRNG 生成）。我将在下面的其他答案中介绍它是否“足够”。

2- 在安全性方面，JWT 使用 HMAC 有区别吗 和使用 RSA 的 JWT？

通常使用 HMAC，因为它们的密钥长度要短得多，因为根本不需要允许客户端访问公钥，因为他们会通过您的 TLS/SSL 证书提供的公钥基础设施对您的服务器进行身份验证.

3- 理想情况下，我应该在哪里存储我所在的对称签名密钥 签署我的代币？目前，我将密钥直接传递给 生成我的令牌的函数。这样做安全吗？

您应该将其存储在无法通过网络读取的应用程序配置文件中。这使得它在每个部署中都不同（例如，在您的预发布环境中提供的令牌不能用于您的生产环境中的身份验证）。

4- 我应该定期更改签名密钥以提高安全性吗？

不，如果它有足够的强度（128 位熵，如上所述），如果它没有被泄露，则不会。

5- 我可以信任我插入到令牌中的用户 ID 声明吗？ 识别发出请求的用户？

是的，这就是重点。如果您的 HMAC 是根据此声明计算的，则无法更改。

6- 令牌是否有“理想”的到期时间？有些人 建议最少 15 分钟，而其他人则说 3 小时即可。

这取决于应用程序的“风险偏好”。例如，如果您的应用程序符合 PCI 规定，则该时间为 15 分钟。如果您乐于让用户将其会话保持更长时间，则可以增加此时间。

7- 我应该担心限制一个令牌的数量吗？ 特定用户可以有？一个用户可能有多个移动设备，并且 在任何时候都可能有多个令牌。在这种情况下，什么都没有 阻止用户从我的服务器获取数千个令牌 前提是他们有他们的凭据。我应该实施一些 跟踪用户拥有的令牌的机制（例如：数据库）？ 如果我有，这似乎违背了 JWT 的目的并增加了复杂性 在验证/生成令牌时进行额外的数据库查询。

不，正如您所说，这首先击败了 JWT 的对象。如果您允许通过 JWT 在客户端管理用户会话，那么您不应该在服务器端跟踪会话。由于令牌是客户端的，因此您的应用程序应该不关心生成了多少令牌，因为您没有额外的开销。如果您担心多个用户以同一个帐户登录，那么 JWT 不是最佳选择 - 服务器端托管系统会更好，因为令牌只能限制为多个同时会话。

8- 我是否需要担心撤销令牌？有人建议拥有 到期时间短的令牌就足够了。其他人指出 如果您不撤销，您将永远无法拥有真正的注销机制 用户注销应用程序后的令牌。是不是错了 等待令牌过期？在安全方面，我什么时候会 需要撤销令牌吗？

再次，这归结为“风险偏好”。如果密码被泄露，则更难撤销可能由攻击者创建的现有会话。与注销链接类似，您所能做的就是响应客户端请求删除 cookie。

一种方法是在 JWT 中包含上次密码更改的日期和时间，该日期和时间包含在 HMAC 计算中。然后将对每个请求进行检查，以确定它是否与数据库中的值匹配。如果没有，那么您将拒绝身份验证令牌并强制用户重新登录。这是您可以使用 JWT 进行撤销的一种方式。

注销比较棘手，因为如果您在令牌中包含“注销日期/时间”，则一个注销请求将注销所有会话，该令牌已在服务器端进行检查。同样，您的风险偏好将决定这是否值得实施，或者是否更容易设置一个较短的有效期以防止攻击者检索到的任何令牌可能会无限期地继续更新（或者直到用户更改密码，如果您使用我之前的解决方案）。