如何使用 RSA、AES 和 JWT 进行安全授权？

Posted 2023-03-10

【中文标题】如何使用 RSA、AES 和 JWT 进行安全授权？

【英文标题】：How to do a Secure Authorization with RSA, AES and JWT?

【发布时间】：2020-07-14 18:24:06

【问题描述】：

首先，让我解释一下我想做什么：

让我们想象 Bob 想要得到 Alice 的授权（经典示例），在我的示例中 Alice 是一个服务器。

让我们也想象一下 Bob 和 Alice 已经获得了每个 RSA 密钥 (4096)。

所以 Bobs 的步骤是：

使用 SHA512 和他的私钥签署信用（明文） 使用 AES CBC 256 加密签名数据和信用 使用 RSA 加密 AES 密钥 向 Alice 发送数据

所以 Alice 会执行上述步骤来解密它并从 Bob 那里验证它。

Alice 验证其 Bob 之后，她生成一个 JWT 令牌并使用她的私钥对其进行签名，并在响应头授权中返回它。

JWT 从 3600 获得 TTL。

到目前为止一切顺利，但我现在的问题是我们如何保护 JWT 不被盗？

确保其已签名，因此无法对其进行修改（除非攻击者从服务器获得了私钥，但我的上帝，那么它无论如何都结束了）。

让我们想象一下，他将能够破解 HTTPS 并窃取令牌，将其放入他的 Header 中，这样他就可以欺骗 Alice 相信他，直到其过期并且他需要再次发送 Credits。

我在考虑两个选项：

选项 1： 始终发送 Credits 和 Decrypted 以验证 Bob。

但这会在每次请求时花费巨大的性能，并且失去来自 JWT 的好处。

选项 2： 发送唯一 ID 并从 Bobs 设备确认（加密，因此与选项 1 相同的问题）

我们可以做些什么来保护它？

也许我想太多了，像往常一样，但我真的很想知道在这种情况下什么是“最佳实践”。

谢谢你的回答

【问题讨论】：

尝试发送带有签名的时间戳

@Makdous 谢谢你我编辑我的问题。忘记指出 TTL 了。

【参考方案1】：

到目前为止一切顺利，但我现在的问题是我们如何保护 JWT 不被盗？

正如你已经发现的那样，它是 https

让我们想象一下他能够破解 HTTPS 并窃取令牌

如果有人能够破解 HTTPS，那么我们遇到的问题比被盗的标头要大得多。默认情况下，您可以信任 https（某些国家/地区的特殊情况除外）

假设通道不安全，例如，您可以单独签署每条消息（对于不安全的通道，仅保护标头是不够的）。

【讨论】：

是的，如果 HTTPS 中断，那将是一个巨大的错误。为此，我使用了内容将单独加密的示例。并且确定如果 Alice 的 PK 会被盗，那么它就结束了，因为你将能够始终由你自己签署 JWT，而 Alice 会相信它。当然，在这个世界上没有什么是安全的，我只是想知道它是否提供了一种处理 JWT 的好方法

【参考方案2】：

好吧，如果 Alice 不确定谁在发送请求，那么 Bob 也不确定，所以这是一个双向问题，没有人可以确定对方的身份，你可以用来自证书颁发机构的签名证书。您在哪里发送带有签名的证书，并且该证书使用证书颁发机构（第三方）的私钥进行签名，从而确保客户端之间的连接服务器是安全的，可以防止任何修改。

【讨论】：

好吧，但是当有人能够窃取标题时，它没有什么可做的吗？我的意思是肯定来自例如 GoDaddy 的证书无论如何都会更好，并且无论如何都要使用 HTTPS。但我的意思是，如果失败了，那么有人无法准备内容，因为它是加密的，但他可以获取标题并使用该身份进行伪造。

假设他偷了标头，然后他必须修改时间戳以使接收者可以接受，这意味着他必须更改与标头一起发送的签名，这将使签名无效因为它是用私钥签名的，最后是证书，它将确保在签名或解密的标头中没有任何内容被修改或更改，所以我发现有人窃取标头并能够重用它的情况几乎是不可能的。

我完全同意这一点。当然他不能修改它，但只要它有效，他仍然可以使用它。也许我没有为下一个请求指出它的好处，爱丽丝会相信它的鲍勃，或者我的思维方式失败了？

请记住，如果将标头封装在所有这些安全层中，中间人无法单独获取标头。

那是真的，但正如我在帖子中所说，我可能在这点上想得有点多，但无论如何感谢你的回答，伙计 =)