使用 IP 地址的 JWT 安全性

Question

我正在使用 Angular 2 和内置于 ASP.NET Core Web API 的后端服务构建一个 Web 应用程序。

对于身份验证，我正在考虑使用 JWT 并将令牌存储在 Secure HttpOnly Cookie 中。

为了额外的安全性，我还考虑在初始登录和初始登录后的每个请求中捕获用户的 IP 地址，如果 IP 地址发生更改，则撤销令牌。

所以我的问题是：

• 这种额外的安全级别值得吗？
• 我正在考虑使用的 IP 检查是否有任何问题？根据我对网络的了解，我认为 IP 地址不会在请求之间合法地改变。即使是这样，我认为这将是非常罕见的。不过，我不会假装我对网络有足够的了解来证实这一点。

编辑 1

（响应答案）。

感谢您回答我的问题。我已经回复了您的一些回复。

我最初的想法是在 cookie 中使用 JWT 连接到 API 不是典型的用例，那你为什么不使用标准的 MVC 应用程序，但这不是你的问题，实际上它同样安全，只要令牌位于安全的 httponly cookie 中（当然实现是正确的）。我觉得这有点不寻常。

我不确定您为什么认为以这种方式使用 cookie 不寻常？

是不是因为大部分时间 cookie 都用于会话状态？我个人认为将令牌存储在安全 cookie 中而不是将令牌保存在 http 标头或本地存储中应该是一个非常典型的用例，因为它更加安全。除非我错过了什么？

所以我想我会问这样做有什么缺点？

这取决于。如果您担心会话被盗，可能是的。如果您将令牌保存在 httponly cookie 中（防止 xss），这比其他任何地方的令牌都更安全，但是您的威胁模型可能会显示不同的威胁并验证您的担忧。通常的问题是你不能这样做，见下文。

此应用程序将处理大量 PPI 信息，因此我确实担心令牌被盗。

很可能会有问题。这取决于您的用户，他们如何以及从何处使用您的应用程序。如果他们使用移动设备，IP地址会发生很大变化，这样的解决方案是不可能的。如果他们是公司内部网络中的公司用户，这是可行的。介于两者之间的任何东西都是灰色区域。一个典型的家庭用户偶尔会更改他们的 IP，大多数人从他们的互联网提供商那里获得动态 IP 分配。 IP 租约通常持续几周（至少在我居住的地方），但 ISP 可以按照他们想要的任何方式进行配置，可以是一天甚至更短。

我对 IP 地址续租的印象是大多数情况下客户端获得相同的 IP 地址。但是我不应该做出我想的那个假设？

但是我可以看到这可能更多是移动设备的问题。一些客户会经常在路上，所以这是你提出的一个很好的观点，但可能会成为一个问题。

您可以选择执行的一个典型解决方案是在登录屏幕上提供此选项。如果用户选择使用 IP 地址验证，他会选择更高的安全性，但接受有时他可能必须重新登录的事实。或者他可以选择较低的安全性，而他的会话更稳定。我认为是否值得向您的用户解释这一点是一个商业决策。

从来没有想过给客户一个听起来不错的选择。

编辑 2

（响应答案）。

我也不确定您的 JWT 是否只有会话 ID，或者您的服务器是否是无状态的并且所有会话数据都在 JWT 中。在第一种情况下，您甚至不需要 JWT，您可以像往常一样传递会话 ID，而标准的 .Net MVC 会为您做到这一点。如果它也是会话数据，默认情况下 JWT 是未加密的，因此最终用户可以看到会话内容，这可能是也可能不是问题。 （并且 JWT 受到其签名的保护，不会被篡改，所以它只关乎机密性，而不是完整性）。将会话数据存储在 JWT 和 cookie 中的 JWT 也可能面临 cookie 大小问题，具体取决于您的目标浏览器。

我的后端 ASP.NET Core Web API 将是无状态的。已经决定使用Angular，所以讨论是一个有争议的问题。

至于为什么我认为以这种方式使用 JWT 有点不寻常：我认为 JWT 主要用于需要将令牌传递到不同的 URL（到不同的服务）时。为此，由于同源规则，httpOnly cookie 显然是不够的。如果您负担得起使用 httpOnly cookie，您可以将会话信息存储在服务器端。

虽然我很想讨论上述主题，因为我的解决方案可能存在缺陷，但我认为权力可能会因为偏离主题而关闭这篇文章？

针对上述主题提出一个新问题可能更合适？

至于导致相同 IP 的续租：嗯，它们并不总是如此。这取决于您的业务案例，但某些 ISP 只会在短时间内为您提供 IP。如果您的用户可以偶尔注销一次，那么有线（家庭）用户可能就可以了。这绝对是移动设备的一个大问题。

Answer 1

我最初的想法是在 cookie 中使用 JWT 连接到 API 不是典型的用例，那你为什么不使用标准的 MVC 应用程序，但这不是你的问题，实际上它同样安全，只要令牌位于安全的 httponly cookie 中（当然实现是正确的）。我觉得这有点不寻常。

说到点子上，您的问题和您对问题的担忧一样非常有效。

这种额外的安全级别值得吗？

这取决于。如果您担心会话被盗，可能是的。如果您将令牌保存在 httponly cookie 中（防止 xss），这比其他任何地方的令牌都更安全，但是您的威胁模型可能会显示不同的威胁并验证您的担忧。通常的问题是你不能这样做，见下文。

我正在考虑使用的 IP 检查会有什么问题吗？

很可能会有问题。这取决于您的用户，他们如何以及从何处使用您的应用程序。如果他们使用移动设备，IP地址会发生很大变化，这样的解决方案是不可能的。如果他们是公司内部网络中的公司用户，这是可行的。介于两者之间的任何东西都是灰色区域。一个典型的家庭用户偶尔会更改他们的 IP，大多数人从他们的互联网提供商那里获得动态 IP 分配。 IP 租约通常持续几周（至少在我居住的地方），但 ISP 可以按照他们想要的任何方式进行配置，可以是一天甚至更短。

所以现实情况是，如果你有一个正常的用户群，你很可能会遇到问题。

您可以选择执行的一个典型解决方案是在登录屏幕上提供此选项。如果用户选择使用 IP 地址验证，他会选择更高的安全性，但接受有时他可能必须重新登录的事实。或者他可以选择较低的安全性，而他的会话更稳定。我认为是否值得向您的用户解释这一点是一个商业决策。

更新以响应编辑 1 :)

至于为什么我认为以这种方式使用 JWT 有点不寻常：我认为 JWT 主要用于需要将令牌传递到不同的 URL（到不同的服务）时。为此，由于同源规则，httpOnly cookie 显然是不够的。如果您负担得起使用 httpOnly cookie，您可以将会话信息存储在服务器端。另外我不确定您的 JWT 是否只有会话 ID，或者您的服务器是否是无状态的并且所有会话数据都在 JWT 中。在第一种情况下，您甚至不需要 JWT，您可以像往常一样传递会话 ID，而标准的 .Net MVC 会为您做到这一点。如果它也是会话数据，默认情况下 JWT 是未加密的，因此最终用户可以看到会话内容，这可能是也可能不是问题。 （并且 JWT 受到其签名的保护，不会被篡改，所以它只关乎机密性，而不是完整性）。将会话数据存储在 JWT 和 cookie 中的 JWT 也可能面临 cookie 大小问题，具体取决于您的目标浏览器。

至于导致相同 IP 的续租：嗯，它们并不总是如此。这取决于您的业务案例，但某些 ISP 只会在短时间内为您提供 IP。如果您的用户可以偶尔注销一次，那么有线（家庭）用户可能就可以了。这绝对是移动设备的一个大问题。

Answer 2

我认为您可以使用 JWT 和 IP 来做到这一点。当用户登录时。捕获会话长度的 IP。在每次登录时捕获 IP，然后使用它来验证令牌是否来自启动会话的所有者。如果另一个 IP 命中系统。强制重新验证和新令牌。 IP+JWT+密码=登录。如果您的移动应用程序需要 1 次登录并始终记住登录信息。用户无需再次输入登录信息。然后将用户名\密码缓存在应用程序中{安全}，然后在IP更改时自动重新发送。使用 SSL 时 JWT 是安全的 Difference between SSL and JWT

Answer 3

很抱歉恢复了这个，但最近我一直在思考加密和安全性并想到了一些东西（我猜这与 HTTPS 所做的非常相似）

当用户登录时，服务器会回复一个普通的问候语（用户信息、JWT 和您需要传递的任何其他数据）+ 您将传递一个公钥

有一个支持任何非对称加密方法（我喜欢 RSA）的后端，并让你的前端（也需要运行相同的加密方法）端接收公钥，加密数据，然后将其发送到服务器请求。

如果用户需要提供的任何数据发生变化，请撤销。

你甚至可以跟踪一个时钟，如果它偏离太多，就撤销。

对于额外的层，让客户端在登录/注册和繁荣时传输公钥，像防护服一样密封通信。