1

我正在调查 Cyber​​Source REST API 并希望测试此处记录的 JSON Web 令牌身份验证方法：https ://developer.cybersource.com/api/developer-guides/dita-gettingstarted/authentication/GenerateHeader/jwtTokenAuthentication.html

我无法复制 JWT 有效负载/声明集部分中描述的 JSON 有效负载的 sha256 哈希。

{
  "clientReferenceInformation" : {
    "code" : "TC50171_3"
  },
  "orderInformation" : {
    "amountDetails" : {
      "totalAmount" : "102.21",
      "currency" : "USD"
    }
  }
}

我尝试在包含有效负载示例的文件上使用二进制和文本格式的 sha256sum 命令。我还尝试在此有效负载的不同排列上运行此命令，例如没有空格或换行符。

我希望得到示例哈希

2b4fee10da8c5e1feaad32b014021e079fe4afcf06af223004af944011a7cb65c

而是得到

f710ef58876f83e36b80a83c8ec7da75c8c1640d77d598c470a3dd85ae1458d3和其他不同的哈希。

我究竟做错了什么？

4

2 回答 2

1

由于所谓的“示例”哈希包含 33 个十六进制字符，因此可以看出它不是 SHA256 的可能有效输出。因此，您无法做任何事情来使您的示例与他们的示例相匹配。

该讨论中还有一个 base64 示例，但它也不是有效的 base64。通过在 base64 中添加一个额外的填充字符“=”，它可以变得有效，并且解码它表明它主要匹配所谓的 SHA256 哈希。

我的猜测是该页面上的值只是人眼看起来的值的示例，而不是您应该完全匹配的测试向量。

于 2019-06-26T13:28:02.007 回答
0

可能你没有做错任何事。散列函数具有雪崩效应，其中输入中的任何不同位都会极大地改变输出散列。如果网站的原始示例使用了不同的编码，或者 JSON 元素的顺序不同，或者甚至有或多或少的制表符、空格、换行符或任何其他“垃圾”字符，您将很难找到网站中显示的哈希的合适消息。

通常，加密解决方案使用规范化来避免此类问题（语义相同消息的不同哈希值）。但是，JWT 规范没有为 JSON 指定任何类型的规范化。

简而言之，我认为您不必担心这一点。只要您使用有效（正确实现）的散列函数，您的 JWT 实现就是正确的。

另外，我注意到JWT 规范没有为 JWT 有效负载指定“摘要”字段。因此，您甚至可能不需要使用此字段。除非 Cyber​​Source REST API 强制要求。

于 2019-06-26T02:13:35.487 回答