5

是的，我已经阅读了@developer.android.com 的所有文档，并且我确实理解了这一切，但有一个基本例外——它是为了什么而引入的。

由于来自 Google Play 的所有订单响应都由任何人都无法访问的私钥签名，并且正在通过配对的公钥进行验证（在我的情况下是在外部服务器上，因此第三人也无法访问）所以根本（几乎）没有办法欺骗。

所有这些随机数只是确保购买的多余方式。更重要的是，文档对这种情况只字未提，当：

  1. 我购买了一件物品；
  2. 生成随机数并将其发送到 Google Play；
  3. 发生崩溃，所以我所有已知的随机数都丢失了；
  4. 让我的应用重新启动并从 Google Play 获得回调；
  5. ...并因未识别 nonce 而拒绝此呼叫！

在上述情况下，用户支付了一个项目并且从未得到它，这是可耻的。当然，我可以将 nonce 存储在某个文件中，并在我的应用程序返回时重新读取它，但这违反了 nonce 的所有原则。

恕我直言，有人刚刚说“嘿，验证过程太简单了，让我们随机添加一些东西，它会更酷！”。所以有人做到了。

或者，你会敞开心扉接受我错过的其他用例吗？否则，我将从我的代码中删除整个随机数部分。

4

4 回答 4

2

您不需要将随机数“存储到磁盘”来解决应用程序崩溃问题。

当您的应用程序崩溃时，您将丢失已知随机数列表。但是，当您的应用重新启动并且您收到一个时，您必须在执行此操作时IN_APP_NOTIFY执行另一个操作，您将生成一个新的随机数并将其添加到已知随机数列表中。GET_PURCHASE_INFORMATIONGET_PURCHASE_INFORMATION

您必须记住的是，随机数是每个GET_PURCHASE_INFORMATION（返回您购买的多件商品）而不是每个购买的商品一个随机数。

正如您所说，您已经实现了自己的方法来避免重放攻击，但是使用随机数曾经是一种安全的方法

于 2012-08-16T12:56:29.890 回答
0

“nonce 就像交易中的盐一样，类似于 *nix 系统存储密码的方式。nonce 用于为使用您的密钥加密的值添加熵，从而在很大程度上消除了两个交易被加密并导致相同的签名，以及其他类似的加密攻击。”

查看queso 的答案

于 2012-07-22T10:12:04.223 回答
0

想象一下，您的用户以 100 美元的价格购买了一件商品。通知您的应用程序有可用的付款数据，应用程序请求数据并且 AppStore 以 PURCHASE_STATE_CHANGED 响应。用户从 AppStore 记录消息 (!) 并保存。

之后，用户伪造了一个通知给你的应用，告诉它支付数据可用（任何人都可以伪造，因为这个通知没有签名）。该应用程序认为“哦，嘿，也许我刚刚崩溃并丢失了有关我的用户刚刚购买的所有信息！？让我们看看 AppStore 有什么要说的”。所以它从应用商店请求数据。用户中断该请求并将先前记录的消息发送到您的应用程序。该应用程序看到该消息，对其进行验证并发现它是有效的（因为它已签名并且全部）。因此，该应用程序将为您提供另一件价值 100 美元的物品。还有一个。就像用户重播录制的消息一样频繁。因此称为：重放攻击。

然而，有一件事可以防止这种攻击：nonce。如果您的应用在其支付数据请求中发送了一个随机数，它希望在 PURCHASE_STATE_CHANGED 回复中收到相同的随机数。由于 nonce 仅使用一次，因此您无法重播以前记录的消息，因为它们与请求中使用的 nonce 不匹配。

于 2012-06-25T13:59:54.340 回答
0

您应该在发送它们之前保存生成的随机数。Android 应用程序可能随时崩溃或关闭，因此通常应保存所有内容。

使用 nonce 的原因是为了防止重放攻击。我远没有资格回答是否需要使用 nonce，但我认为它的存在是有原因的。

于 2012-05-09T14:06:30.470 回答