当攻击者获得用于生成JWT的秘密时会发生什么？

据我了解JWT验证它基本上是这样的：当攻击者获得用于生成JWT的秘密时会发生什么？

用户发送的登录凭据到服务器
如果登录凭据是正确的，服务器发出包含的用户ID和用户名一智威汤逊（或任何你想要的在有效载荷，以确定
是使用应用程序范围内的秘密，这应该被存储在环境变量
JWT是由用户存储生成此JWT用户），例如在localStorage的和与每一个请求发送到标头
使用应用程序范围的秘密验证auth头中的JWT。如果验证成功，我们知道谁发送了请求，并且请求是否被授权。

但是如果攻击者获得访问用于生成智威汤逊秘密的信息会发生什么？是不是像主密码？随着秘密和用户ID /用户名，任何人都可以为任何用户发布JWT，并基本上接管任何帐户。这不是一个巨大的缺陷，因为一小部分信息会危及整个系统（而不仅仅是一个用户帐户）？还是我误会了？

来源

2015-06-19 Ole Spaarmann

此页面指示最佳实践：https://stormpath.com/blog/jwt-the-right-way/“保护用于计算和验证签名的秘密签名密钥。秘密签名密钥只能由发行人和消费者，它们不应该在这两方之外访问。“jwt示例代码有一个硬编码的密钥，很多人都会对他们的代码做同样的事情，从不评估实践，然后一部分人将这些代码存储在公共存储库中。危险，顺便说一句 –

是的，当然它不应该被硬编码，它不应该在你的回购（或在Github上为上帝着想）......但是让我说我有几个应用程序的实例，通过启动新实例因此我需要将秘密传递给我的应用程序的每个实例，这意味着我必须将秘密存储在我的服务器上的某个地方，因为我不打算手动启动实例，输入只存在于我的应用程序中的秘密现在我的问题是：如果有人能够访问这个秘密怎么办？整个应用程序基本上都是公开的，对吧？ –

正如我刚才想到的那样，让攻击者更难以为每个用户添加一个随机的，唯一的，串到存储在用户信息中的JWT。任何攻击者都可以轻松读取，但只能用于当前登录的帐户。这样服务器就会立即知道服务器上是否生成了JWT。不利的一面是，每一个保护API端点的请求都会影响数据库，查询用户表来验证字符串。 –

您正在描述一种JWT受到对称密钥（即发送者和接收者之间共享的秘密）完整性保护的机制。这只是保护智威汤逊的一种选择，虽然不是最安全的选择，因为它依赖于可能在两端丢失或被盗的秘密。在发件人不能保密的情况下，如浏览器内的客户端也没有用。当发送者需要为每个接收者管理一个共享密钥的多个接收者时，它也较不易管理/可扩展。

使用公钥/私钥对保护智威汤逊存在更安全的选项。在这种情况下，智威汤逊将使用只有发件人知道的私钥进行签名，并且接收方只能知道公钥。当然，如果这个私钥丢失了，它将允许攻击者生成任意的JWT并冒充用户，但由于攻击者显然已经可以访问服务器端基础设施，他甚至不需要模拟用户访问服务器端信息。

所以你是对的：受共享秘密保护的JWT往往不太受欢迎，因为它具有安全意义，但有一种更好的方法可以使用PKI机制来保护它。

来源

2015-06-20 07:14:14

如果你是所有这些加密的东西，我建议你阅读Diffie-Hellman密钥交换技术。它允许两方在没有先知道共同秘密的情况下进行安全对话。它利用PK加密技术，基本上是以下类比：

1）我把一个挂锁放在一个盒子上，并将它发送给你邮寄给你。盒子里面有一个我想让你知道的秘密，在这种情况下是一个会话密钥。 2）您将收到包裹并将自己的挂锁放在箱子上，通过邮件发回给我。 3）我收到带有两个锁的盒子，并取出我自己的锁，然后将锁仅发送给您。 4）您再次收到包装盒，取出您的锁并获取内容：会话密钥，除了我之外，其他任何人都不会看到会话密钥。

来源

2015-06-20 23:07:15

当攻击者获得用于生成JWT的秘密时会发生什么？

回答

相关问题