RSA JWT关键轮换期？

Question

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

JWT正在使用2个不同的密钥进行签名.

使用RSA512算法使用4096位密钥对刷新令牌进行签名.

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

通过RSA256算法使用1024位RSA密钥对访问令牌进行签名.

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

由于4096位验证过程需要更长的时间,因此我对"速度"的建议已经采用了这一点,但似乎对刷新令牌的请求较少,安全性的权衡似乎是公平的.

另一方面,访问令牌在资源服务器端点进行验证,并且它们被更频繁地发送,因此我选择了更短(256)的签名,该签名使用更快的1024位密钥进行.

我知道钥匙"几乎"不可能破坏......但建议使用钥匙旋转？

我将jks(密钥库)保存在auth服务器和资源服务器上的私有文件夹中.密钥库包含2个密钥对,一个用于刷新令牌签名/验证,另一个用于访问令牌签名/验证.

我需要刷新/形成新密钥吗？如果是这样......多久一次？建议的方法是什么？

在负载均衡器后面可以有多个auth和资源微服务实例...因此RAM生成的密钥是否为,因为它们不会在实例之间传播.

我已经看过可能有一个"密钥服务器",可以说创建新密钥并将它们附加到密钥库并将新的jks文件更新为新的密钥对...类似于:

因此,例如,每隔15秒,EC2 auth服务器和资源服务器ping密钥服务器,请求当前jks的副本(和版本检查).

有什么建议？

谢谢!

Answer 1

JWT RSA 密钥大小

将 RSA 密钥更正为 2048 位，即当前推荐的大小（2020 年）。

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

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

请参阅有关我的 SSL 证书应使用什么 RSA 密钥长度的相关答案？

JWT 密钥轮换

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

活动的 JWT 公钥可以从 OIDC 服务器中获取，在像/.well-known/keys. 请参阅 OIDC 服务器的文档。

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

• 通常的做法是在 1 小时到 1 周之间定期检索密钥。
• 定期自动重启的应用程序（Web 容器）可能会在启动时加载密钥，而不会在运行期间主动刷新它们。
• 服务器通常有一个预定的重启周期（可能是每月或每季度），对任何东西可以运行的时间设置上限。
• 一个例子：Apache 插件mod_auth_openidc默认每小时检索一次密钥。设置OIDCUserInfoRefreshInterval

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

• 通常的做法是在 1 到 12 个月之间定期轮换密钥。
• Okta 提供了带有 90 天密钥的示例。
• 像 Facebook 这样的网站几乎从不要求用户重新验证（几个月？几年？您是否必须再次登录？），因此签名密钥必须持续数月，而银行网站不需要支持多个月的会话。
• 通常没有必要比每月更频繁地轮换密钥。它只会突出软件重新加载不够频繁的微妙问题，并防止“长时间”会话。

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

• 签名密钥的有效期为 1 年。
• 签名密钥每 6 个月轮换一次。
• 这意味着/.../keys始终至少有 2 个可用的密钥。一把活动钥匙和一把未来的钥匙等待替换它。
• 好处：
• 这使应用程序有足够的时间来获取下一个密钥（6 个月），无论是通过主动刷新还是被动重启。
• 6 months is long enough that keys can be hardcoded into libraries/applications for special use cases that require it. For example we have HPC-like compute clusters deploying 10000 tasks/processes at once, that might DDoS the shit out of the OIDC server if every single one of them tried to fetch keys remotely on startup.
• Gotta rotate often enough (6 months absolute top) for anything to work and be tested. If a developer performs some integrations and doesn't handle rotation well, it's gonna blow up within 6 months and they can fix it (hopefully still in testing phase or with limited users). If the rotation happens after 2 years instead, nobody will notice it's gonna break until it breaks and there's nobody to fix it, all the original developers having long left.

DDoS

By the way, timelines are never in seconds, it's funny the question mentions seconds.

An authentication system is depended upon by everything in a company, when "everything" (thousands of services) is trying to ping the same service every few seconds (or even few minutes), that's a quick way to understand the concept of permanent accidental DDoS.

One of the primary goals of JWT was precisely to not need a central service to verify tokens (a massive constantly-loaded single-point-of-failure). You can embrace the goal of limiting dependencies by only loading signing keys -remotely- once on startup (assuming the services you run are restarting periodically).