security - RSA JWT key 轮换周期？

Question

我已经创建了一个基本的 JWT 生成器，但需要几个方面的建议。我一直在用JWT.io的指南和 auth0/java-jwt库/repo 来生成 token 。

JWT 使用 2 个不同的 key 进行签名。

使用 4096 位 key 使用 RSA512 算法对刷新 token 进行签名。

.sign(Algorithm.RSA512(rsaPublicKey, rsaPrivateKey));

访问 token 通过 RSA256 算法使用 1024 位 RSA key 进行签名。

 .sign(Algorithm.RSA256(rsaPublicKey, rsaPrivateKey));

我已经针对“速度”提出了建议，因为 4096 位验证过程需要更长的时间，但似乎刷新 token 的请求较少，安全性的权衡似乎是公平的。

另一方面，访问 token 在资源服务器端点进行验证，并且发送的频率更高，因此我选择了更短的 (256) 签名，该签名由更快的 1024 位 key 执行。

我知道 key “实际上”是不可能打破的……但推荐 key 轮换？

我将 jks( keystore )保存在身份验证服务器和资源服务器上的私有(private)文件夹中。
keystore 拥有 2 个 key 对，一个用于刷新 token 签名/验证，另一个用于访问 token 签名/验证。

我需要刷新/形成新 key 吗？如果是这样……多久一次？
推荐的方法是什么？

负载均衡器后面可以有多个身份验证和资源微服务实例......所以 RAM 生成的 key 是不可以的，因为它们不会在实例之间传播。

我已经看过可能有一个“ key 服务器”，它可以说创建新 key 并将它们附加到 keystore 并分发新的 jks 文件以使用新的 key 对进行更新......类似于:


例如，每 15 秒，EC2 身份验证服务器和资源服务器 ping key 服务器，请求当前 jks 的副本(和版本检查)。

有什么建议吗？

谢谢!

Answer 1

JWT RSA key 大小

将 RSA key 更正为 2048 位，即当前推荐的大小(2020 年)。

1024 位 RSA key 被认为是弱 key ，在处理高度 secret 信息时已被 NIST 禁止使用。 (提示:中央身份验证系统尽可能保密)。如果有足够的计算能力，它可以被破解，记住任何大型组织都可以访问具有 10k+ CPU 的数据中心。

4096 个 key 是可能的，但验证速度可能比 2048 个慢 10 倍(复杂性与大小不是线性的)。仔细考虑性能影响。身份验证 token 将在任何地方使用并经过无数次验证。

请参阅 What RSA key length should I use for my SSL certificates? 上的相关回答

JWT key 轮换

假设沿 OpenID Connect (OIDC) 使用 JWT。

事件 JWT 公钥可以从 OIDC 服务器获取，在端点上，如 /.well-known/keys .请参阅 OIDC 服务器的文档。

应用程序应在启动时检索公钥并定期刷新它们 .频率没有正式的标准？

通常的做法是在 1 小时到 1 周之间定期检索 key 。

定期自动重启的应用程序(Web 容器)可能会在启动时加载 key ，而不会在运行期间主动刷新它们。

服务器通常有一个预定的重启周期(可能是每月或每季度)，对任何东西可以运行的时间设置上限。

一个例子:Apache 插件 mod_auth_openidc默认情况下每小时检索一次 key 。设置 OIDCUserInfoRefreshInterval

现有 token 在其签名 key 轮换后失效，如果应用程序没有跟上较新的签名 key ，则不会接受新 token 。因此，要想使事情顺利进行，就必须要考虑。

通常的做法是在 1 到 12 个月之间定期轮换 key 。

Okta 提供 their examples带有 90 天的 key 。

像 Facebook 这样的网站几乎从不要求用户重新验证(几个月？几年？您是否必须再次登录？)，因此签名 key 必须持续数月，而银行网站不需要支持多个月的 session 。

通常没有必要比每月更频繁地轮换 key 。它只会突出软件重新加载不够频繁的微妙问题，并防止“长时间” session 。

我的个人建议是确保最大的安全性和最小的麻烦 ，已为大型组织中的数千个系统中的数千个应用程序管理单点登录。

签名 key 的有效期为 1 年。

签名 key 每 6 个月轮换一次。

这意味着 /.../keys 至少有 2 个可用的 key 在任何时候。一把事件 key 和一把 future 的 key 等待替换它。

福利:

这使应用程序有足够的时间来获取下一个 key (6 个月)，无论是通过主动刷新还是被动重启。

6 个月足够长，可以将 key 硬编码到需要它的特殊用例的库/应用程序中。例如，我们有类似 HPC 的计算集群，一次部署 10000 个任务/进程，如果它们中的每一个都试图在启动时远程获取 key ，则可能会 DDoS 从 OIDC 服务器中删除。

必须经常轮换(6 个月绝对最高)，以便任何工作和测试。如果开发人员执行了一些集成并且不能很好地处理轮换，它会在 6 个月内爆炸，他们可以修复它(希望仍处于测试阶段或用户有限)。如果轮换发生在 2 年后，那么没有人会注意到它会损坏，直到它损坏并且没有人来修复它，所有原始开发人员早就离开了。

分布式拒绝服务

顺便说一句，时间线永远不会以秒为单位，这个问题提到秒很有趣。

公司中的一切都依赖于身份验证系统，当“一切”(数千个服务)每隔几秒钟(甚至几分钟)尝试 ping 同一个服务时，这是理解永久意外 DDoS 概念的快速方法.

JWT 的主要目标之一正是不需要中央服务来验证 token (大量不断加载的单点故障)。您可以通过仅在启动时远程加载签名 key 一次(假设您运行的服务定期重新启动)来实现限制依赖项的目标。