Android InApp Billing – для чего действительно нужны ноты?

ДА, я прочитал все docs @ developer.android.com, и я все понимаю с одним основным исключением – для чего он был введен.

Поскольку все ответы на запросы от Google Play подписываются закрытым ключом недоступного для каждого пользователя и проверяются парным открытым ключом (в моем случае на внешнем сервере, поэтому он также недоступен для третьего лица), просто (почти) нет способа пародия.

Все эти nonce – просто избыточный способ обеспечения покупок. Более того, документы ничего не говорят о ситуации, когда:

  1. Я покупаю товар;
  2. Создайте nonce и отправьте его в Google Play;
  3. У вас крушение, поэтому все мои известные ноты потеряны;
  4. Перезапустить приложение и получить обратный вызов из Google Play;
  5. … И отказаться от этого звонка из-за того, что не признал nonce!

В описанной выше ситуации пользователь платит за предмет и никогда не получает его, что это постыдно. Конечно, я могу хранить nonces в каком-то файле и перечитывать его, когда мое приложение возвращается, но оно нарушает все принципы для nonces.

ИМХО кто-то просто сказал: «Эй, процесс проверки слишком прост, давайте добавим что-то еще со случайностью, это будет намного круче!». Так кто-то это сделал.

Или, не могли бы вы открыть мой разум в каком-то другом случае? В противном случае я удаляю часть nonces из моего кода.

Вам не нужно хранить «nonce» на диске для учета сбоя приложения.

Когда ваше приложение выйдет из строя, вы потеряете список известных несетов. Однако, когда ваше приложение перезагружается и вы получаете IN_APP_NOTIFY вам необходимо выполнить еще одну GET_PURCHASE_INFORMATION когда вы сделаете это GET_PURCHASE_INFORMATION вы GET_PURCHASE_INFORMATION новое nonce и добавите его в список известных nonces.

То, что вы должны помнить, – это nonce – одно из GET_PURCHASE_INFORMATION (которое возвращает вам несколько купленных предметов), а не одно очко за купленный предмет.

Как вы уже сказали, вы внедрили свой собственный способ избежать Replay Attacks, но использование nonce – это один такой безопасный метод

Перед отправкой вам следует сохранить сгенерированные символы . Приложения Android могут выходить из строя или закрываться в любой момент, поэтому в общем случае все должно быть сохранено.

Причиной использования nonces является предотвращение повторных атак . Я далек от квалификации, чтобы ответить, нужно ли использовать nonce или нет, но я предполагаю, что он существует по какой-то причине.

Представьте, что ваш пользователь покупает товар, чтобы сказать 100 долларов. Ваше приложение уведомлено о наличии доступных платежных данных, приложение запрашивает данные и ответы AppStore с помощью PURCHASE_STATE_CHANGED. Пользователь записывает сообщение (!) Из AppStore и сохраняет его.

Позже пользователь подделывает уведомление о вашем приложении, сообщая ему, что доступны платежные данные (любой может подделать это, так как это уведомление не подписано). Приложение думает «о, эй, возможно, я просто разбился и потерял всю информацию о покупке, которую только что сделал мой пользователь!» Давайте посмотрим, что скажет AppStore ». Поэтому он запрашивает данные из магазина приложений. Пользователь прерывает этот запрос и отправляет ранее записанное сообщение в ваше приложение. Приложение видит сообщение, проверяет его и обнаруживает, что оно действительно (потому что оно подписано и все). Таким образом, приложение предоставит вам еще один ценный товар стоимостью 100 долларов. И другой. Так же часто, как пользователь воспроизводит записанное сообщение. Поэтому называется: повторная атака.

Есть одна вещь, которая предотвращает такую ​​атаку: nonce. Если ваше приложение отправляет nonce в свой запрос для данных платежа, он ожидает получить тот же самый номер в ответе PURCHASE_STATE_CHANGED. Поскольку nonce используется только один раз, вы не можете воспроизводить ранее записанные сообщения, потому что они не совпадают с nonce, который использовался в запросе.

«Nonce действует как соль транзакции, подобно тому, как системы nix хранят пароли. Nonce используется для добавления энтропии к значению, которое зашифровано вашим ключом, в значительной степени устраняя вероятность зашифровки двух транзакций и приводя к Та же подпись и другие подобные криптографические атаки ».

См. Ответ queso