【问题标题】:JWT with user password in key密钥中包含用户密码的 JWT
【发布时间】:2018-04-13 20:31:01
【问题描述】:

我想在我的应用程序中使用 JWT。 现在我想知道将用户密码与私人秘密结合使用作为签署我的令牌的密钥是否安全。这样,如果用户更改他/她的密码,令牌就会失效。 但也许它让我的私人秘密变得脆弱? 感谢您对此的想法!

【问题讨论】:

  • 我想这使得验证有点困难,因为我必须事先加载用户。但这应该是可行的。

标签: security jwt signing


【解决方案1】:

通常的做法是使用相同的密钥对所有令牌进行签名。简化管理,避免每次请求都查询数据库。

使用密钥+用户密码签名是可行的,并且具有允许撤销令牌的优点(具有注释的缺点)。

确保您的签名密钥足够安全,可以从用户密码导出,并且具有所选签名算法的推荐长度。请勿直接存储或使用用户密码。

【讨论】:

  • 感谢您的回答。假设我大部分时间都收到有效请求,我最终还是会为用户查询数据库。所以我想这实际上并没有那么大的缺点?
  • 影响取决于您的架构。如果您使用数十个查询实现繁重的服务,那么额外的无关紧要。但是,如果您使用微服务,那么它可能会影响响应时间。另请注意,更改密码可能不是一个常见的请求,但您正在惩罚所有支持此操作的服务。
【解决方案2】:

秘密是客户端和服务器之间交换的预共享字符串。 所以在你的情况下:

         SecretString= PresharedSecret + ClientPassword

因此,每次客户端传递 JWT 令牌时,您都需要从数据库中检索密码或通过某种方式预加载密码并检查密码是否更改以验证令牌。

这可能会导致以下情况:

  1. 每当客户忘记密码时,您可能需要进行代价高昂的数据库调用
  2. 它会以一种方式增强安全性,因为任何更改密码的人都无法在知道之前的 SecretString 的情况下与服务器通信。 需要确定一个新的预共享密钥......并使用新注册的密码进行验证。

总的来说,它确实提高了安全性。但是,这取决于基础设施的目的或用途。如果它是一个用户经常忘记密码的系统.. 这可能不是一个很好的选择。

【讨论】:

    猜你喜欢
    • 2019-03-15
    • 1970-01-01
    • 2021-12-26
    • 2015-03-14
    • 1970-01-01
    • 2018-01-09
    • 2018-02-02
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多